V2: pending form and permission reads bootstrap idle session locations #53918

Summary

Listing pending forms or permissions for an idle session acquires its full Location service graph. A client restoring session state can therefore create otherwise unused locations, watchers, and MCP-related services just to receive an empty list.

Environment

• opencode version: Desktop fork based on 2.0.24; the affected paths are also present in upstream v2 at 216c31174.
• OS: Linux 7.2.8+deb14-amd64, x64.
• Terminal: Desktop; diagnostic shell reports xterm-256color.
• Shell: /bin/zsh.
• Install/channel: locally built, packaged Desktop using the production/latest channel.
• Active plugins: local provider/quota and tool-routing plugins are installed. The regression should be reproduced in an isolated server test without those plugins, rather than attributed to them.

Reproduction

1. Create a session whose Location is not currently loaded.
2. Request GET /api/session/:sessionID/form or GET /api/session/:sessionID/permission.
3. Inspect the Location service map or count Location resource acquisitions.

The form-list endpoint provides FormLocationMiddleware, which acquires the session's instance. The permission-list handler explicitly calls instances.provide(session).

Expected Behavior

An existing session in a cold Location has no in-memory pending forms or permissions. Return an empty list without constructing the Location graph. For a warm Location, retain its existing scoped resources while reading and return its actual pending prompts. Preserve unknown-session errors and the existing sessionID=global form-placement behavior.

Actual Behavior

Read-only polling constructs the full Location graph before returning the list, including Location watchers and MCP-related services.

Additional Context

An incident on the workstation included earlyoom sending SIGTERM to the Desktop renderer twice. The preceding application process group recorded a 24 GB memory peak and a 16.5 GB swap peak; those are whole-group numbers, not a measurement of the renderer alone. After a server restart, its log showed 87 distinct Location boots and 18 MCP session-capacity failures.

The diagnostic archive contained form/permission reads for 54 sessions spanning 25 of those booted Locations. These observations motivate investigation, but do not prove that this endpoint defect alone caused the entire memory peak.

Related: #51003 and #53046 concern MCP connection lifecycle; #53049 and #53050 concern client request scheduling. This report concerns unnecessary Location acquisition by pending-prompt reads.