feat(mcp): expose attachment upload and send

[juliusmarminge]

Part 14/16 of the shared-core and MCP stack. Based on #10563. Next: #10565.

Expose signed upload preparation, pending-upload discard and an attachment-aware send tool using the existing upload, claim and thread-send services.

t3_thread_send remains unchanged. The new t3_thread_send_attachments checks target ownership and permission ceilings. Each call is a new message; claimed files are retained when dispatch outcome is uncertain. Provider support stays in adapters, and no keyed replay protocol is added.

Attachment claiming and send execution now go through ThreadMessageIntake, shared with RPC. MCP retains only credential/target checks, canonical owned attachment references, and response mapping.

MCP-only rebuild of #8700, preserving attribution to Julius Marminge's original work. Original branches remain available for separate service follow-ups.

Validation: The composed stack passes 94 tests across 12 focused files, including shared core MCP and real MCP/V2 integration, attachment intake, project RPC/service contracts, and client model command selection. Server/contracts/shared/client-runtime typechecks and targeted format/lint/diff checks pass. New behavior coverage lives with the shared operation; no per-tool mock suite was added. Current-head CI is shown below.

Layer size: 5 files, +193/-0. No domain-service production implementation or documentation files change in this MCP layer.

Prepared with Codex in the OpenAI agent runtime.

Note

Expose attachment upload, discard, and send as MCP tools

• Adds the AttachmentToolkit with three destructive tools: t3_attachment_prepare_upload, t3_attachment_discard, and t3_thread_send_attachments
• t3_thread_send_attachments resolves attachment references against the target thread's stored attachments, rejects archived threads, and sends a new MCP-originated agent message in automatic mode, returning message and run identifiers
• resolveAttachmentReferences keeps pending-upload references as-is, replaces known IDs with stored metadata, and fails unknown IDs with an invalid-request MCP failure
• Upload-service errors map to unavailable failures; dispatch errors map to orchestration or unavailable failures depending on type
• Behavioral Change: t3_thread_send_attachments accepts 1–8 attachments and an optional message capped at 120,000 characters; references that are neither pending uploads nor in the target thread's stored set are rejected

^{Macroscope summarized 71fa7c9.}

[github-actions]

Thread transfer impact

⚠️ The latest CI run did not produce a thread transfer result for 71fa7c9.

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 exposes three new destructive MCP operations that persist uploads and create attachment-bearing thread runs, materially expanding the production tool surface. An unresolved High-severity finding also reports that pending-upload metadata can be client-forged during attachment claiming, requiring review before merge.

Not approved because:

• 1 blocking correctness issue found at or above your repo's Minimum Blocking Severity

No code changes detected at 71fa7c9. Prior analysis still applies.

^{Adjust the Minimum Blocking Severity for this repo — including turning it Off — in Settings. You can add or adjust custom eligibility rules. Learn more.}

[cursor]

Bugbot is paused — on-demand spend limit reached

Bugbot uses usage-based billing for this team and has hit its on-demand spend limit.

A team admin can raise the spend limit in the Cursor dashboard, or wait for the next billing cycle to continue.