feat(threads): add cross-provider conversation forks

[fabianclain]

When a provider's quota is exhausted, users need a way to continue their conversation with another provider without changing the original session. This adds a manual conversation fork on web, desktop, and mobile: choose a provider/model, create a new thread, and open it after the transcript handoff is recorded.

The environment reads the full persisted user/assistant history and carries it as a child-owned transcript attachment through the existing provider turn flow. The new session does not reuse the source resume cursor or modify the source session. Forks retain textual source identification, support retries and forks of forks, and require no database migration. Older servers do not expose the action.

The child displays the handoff and attachment rather than cloned historical bubbles. Binary attachments, tool activity, provider internals, and checkpoint history are excluded. The source must have no active or pending turn; transcript size, provider permissions, and context capacity still apply. Both threads share the workspace.

Related to #3797, which describes switching within the original conversation. This implementation creates a separate thread. Potential overlap with the orchestration work in #2829 needs maintainer review.

Validation:

• 108 focused tests passed, covering source preservation, fresh provider sessions, transcript completeness, routing, concurrency, retries, authorization, and client selection state.
• Typechecks passed for server, contracts, client-runtime, web, and mobile.
• Targeted lint, formatting, and diff checks passed. Existing lint warnings remain.
• No repository-wide checks were run. Native mobile linters were unavailable; no Swift/Kotlin files changed.

Before marking ready for review:

• Verify the integrated web/desktop and mobile flows in real clients.
• Verify a handoff between live providers.
• Attach before/after UI screenshots.
• Confirm scope and overlap with the related upstream work.

Model/harness: GPT-6 / Codex, with native subagents.

[juliusmarminge]

Thanks for the PR. We're not taking changes to the orchestration and provider layers right now: that part of the server is being rewritten for V2, and merging into the current code would either conflict with or be thrown away by that work.

Closing for now. If this is still an issue once V2 lands, please reopen (or open a fresh PR against the new code) and we'll take a proper look.