refactor(server): share attachment message intake

[juliusmarminge]

Part 3/16 of the shared-core and MCP stack. Based on #10578. Next: #10554.

RPC and MCP separately sequenced pending attachment claims and message execution. This extracts ThreadMessageIntake operations around the existing claim, dispatch/send and ThreadLaunch services, then makes RPC use them. The MCP consumers follow in their own layers.

A launch or dispatch error can follow a durable message commit. Intake releases copies proven unused by the returned durable message/events, including accepted replays, and by typed pre-acceptance failures. It retains copies when acceptance is uncertain; a typed claim failure still cleans its partial batch before dispatch. This removes the RPC blanket error cleanup that could delete accepted message files. It may retain unused copies on uncertain failures. There is no new receipt store, retry journal, lock, provider logic, or service identity. Startup queuing, provenance, analytics and wire mapping stay at the RPC boundary.

Validation: AttachmentClaims, ThreadLaunch and ThreadManagement suites: 38 tests passed; server typecheck passed. One shared real V2 test accepts a launch, loses its result, and proves persisted attachment bytes survive. It also proves launch/command/send replays leave exactly the three accepted files, and nonexistent-project/thread failures add no orphaned copies. Existing partial-claim cleanup coverage remains.

Layer size: 4 files, +379/-150. No MCP tools are introduced in this prerequisite.

Prepared with Codex in the OpenAI agent runtime.

Note

Share attachment intake logic across dispatchCommand, sendToThread, and launchThread handlers

• Adds shared intake handlers in ThreadMessageIntake.ts that claim pending attachments before processing and release them based on outcome.
• Introduces dispatchWasNotAccepted classifier to distinguish definite pre-acceptance failures (projection errors, provider adapter errors, rejected commands, ID conflicts) from uncertain failures.
• releaseUnusedClaims removes only claimed paths absent from the accepted result, preserving referenced copies.
• WebSocket handlers in ws.ts delegate to the shared intake logic instead of doing attachment claiming inline; launch RPC now uses tag-specific error conversion for AttachmentClaimError, ThreadLaunchError, and ServerRuntimeStartupError.
• Adds a filesystem-backed integration test in ThreadLaunchService.test.ts covering uncertain launch replay, pre-acceptance failure cleanup, idempotent retries, and attachment byte preservation.
• Risk: failures previously classified as definite (any observed error released all claims) are now retained when the dispatchWasNotAccepted classifier marks them uncertain; reviewers should verify that unmatched thread-management errors in the classifier do not cause attachment leaks for scenarios previously cleaned up.

^{Macroscope summarized 4cfe358.}

[github-actions]

Thread transfer impact

⚠️ The latest CI run did not produce a thread transfer result for 4cfe358.

This comment will update automatically after the next completed run.

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — This PR changes production WebSocket dispatch and launch behavior by centralizing attachment intake, altering cleanup after uncertain acceptance, and preserving attachments for replay. The added tests cover the primary durability and retry scenarios, but the new error-sensitive runtime logic merits human review.

^{You can add or adjust custom eligibility rules. Learn more.}