fix(server): accept synthetic messages and compaction without booting a session's folder - #60801

Synthetic messages and compaction requests now succeed even when a session's working folder is asleep or deleted.
Posting a synthetic message or requesting compaction only writes a durable item into the session's inbox in SQLite. Neither route needs the session's folder service container booted on the HTTP request thread, and normal prompt execution is unchanged.

❌ Before

1. ❌ POST /api/session/:sessionID/synthetic and POST /api/session/:sessionID/compact ran the session folder middleware before entering the handler.
2. ❌ Every call booted the session's full folder service container even when resume: false.
3. ❌ If the session's git worktree had been deleted, both routes failed with 400.

✅ After

1. Both routes go straight to the global session service, matching revert.commit and wait.
2. Recording a synthetic note (resume: false) or compaction barrier leaves sleeping folder containers asleep.
3. Sessions whose worktrees were pruned still accept synthetic notes and compaction requests.

- POST /synthetic or /compact -> boot session folder container -> write SQLite inbox row
+ POST /synthetic or /compact -> write SQLite inbox row directly

📊 Numbers: HTTP requests against cold and deleted session folders

The new server test fails before the change (sleeping folders boot and deleted folders return 400) and passes after (1 pass, 8 assertions).

👀 Read: packages/protocol/src/groups/session.ts around session.synthetic and session.compact, checking that neither handler in packages/server/src/handlers/session.ts reads Location.Service. The rest is routine OpenAPI regeneration.

_{🔍 Found in a code audit · no user reports · verified with an embedded server test}

Added by the opencode bot (AI-generated).

Public API: session.synthetic and session.compact no longer list LocationNotFoundError in their 404 response (backwards compatible)