[Bug]: Forked OpenCode threads whose parent's native session was deleted fail every send with an opaque "Provider turn failed to start" (forkThread error, 5 silent retries) #27709

Before submitting

• I searched existing issues and did not find a duplicate. (Closest are [Bug]: Forking an OpenCode thread right after Stop fails with "Cannot fork OpenCode session ... while it is still working" #24549 and [Bug]: V2 run stays starting forever after provider-turn.start exhausts its retries — no Stop button, settle refused, only Delete clears it (Pi provider, desktop) #13392 — different causes/symptoms, described below.)
• I included enough detail to reproduce or investigate the problem.

Area

apps/server

Environment

• T3 Code (backend): 0.1.6-nightly.20261030.3904, serving a remote workspace (Linux arm64 VM), backend on the same host
• OpenCode: 2.2.3 (latest channel), spawned by T3 as opencode serve --hostname=127.0.0.1 --port=<ephemeral>
• OS: Ubuntu (Linux arm64) on an Oracle Cloud VM
• The conversation was created via "Forked from conversation" in the web app (app.t3.codes)

Steps to reproduce

Repro requires background knowledge, as the state being dangled is internal, but every step here is deterministic:

1. On an OpenCode-provider thread, run turns normally. T3 records a native OpenCode session id (e.g. ses_e72eeb05……) for the run in its orchestration state.
2. Have that native OpenCode session deleted from OpenCode's session database (in my case it disappeared after the run was interrupted/cleaned up earlier in the day — T3's own runs failed/settled that day and OpenCode no longer had the session: 0 rows in the session table for that id).
3. Fork the thread from an earlier response ("Forked from conversation").
4. Send any message in the fork.
5. Repeat step 4 a few times.

Result: every send in the fork fails, permanently, with Provider turn failed to start.

Expected behavior

• After the fork, T3 should fork the provider thread against a native session that still exists. If the referenced native session is gone, it should fall back (e.g. fork with truncated parent context / start a fresh native thread seeded with the forked message history) instead of referencing a deleted id forever.
• The underlying error should surface in the UI, not just the generic Provider turn failed to start.
• The fork's turn should start once, succeed/fail visibly, and not consume 5 silent retries per send forever with no fault being surfaced or healed.

Actual behavior

Every send in the fork failed immediately:

• UI: Provider turn failed to start. (no underlying cause, on all sends)
• T3's internal effect spans showed the actual error on every attempt:

OpenCode2Adapter.forkThread → ProviderAdapterForkThreadError: Failed to fork
opencode provider thread
provider-thread:provider:opencode:native-thread:pending%3Arun%3Athread%3A428bfe96-8167-44b3-92c6-5875c965f463%3Aordinal%3A1

ProviderTurnStartService.loadFromProvider
  → orchestrationV2.providerTurnStart.start
    → ProviderTurnStartError
      → OrchestrationEffectExecutionError

• The run attempt provider_turn_id is always null — a provider turn never even began.
• The provider-turn.start effect retried 5 attempts (its attempt_count) and never produced any progress message to the user; last_error was never surfaced.
• Not a credential/model issue: the same model (nebius/deepseek-ai/DeepSeek-V4.1-Flash-1017 variant high) reproduces fine via opencode run on the same workspace and the same T3-spawned OpenCode server boots cleanly, but never receives a prompt request — the failure happens inside T3's forkThread before any call to OpenCode.
• Note the fork's provider thread id still encodes the parent thread's id (run:thread:428bfe96…ordinal:1) as the fork source, which is the missing native session.

Evidence

• Backend trace (server.trace.ndjson, ~20 Failure effect-spans at the failure timestamp, repeating per send): OpenCode2Adapter.forkThread → ProviderTurnStartService.loadFromProvider → ProviderTurnStartError → OrchestrationEffectExecutionError.
• T3 orchestration projections (orchestration_v2_projection_run_attempts / _nodes / _provider_turns): all 4 run attempts on the fork are failed with providerTurnId: null, all completed within ~5 s of the send.
• The referenced native OpenCode session ses_e72eeb05… has 0 rows in OpenCode's session table — the session no longer exists, but T3's fork path still targets it through the parent's provider-thread id.

Why this is a distinct bug

• [Bug]: Forking an OpenCode thread right after Stop fails with "Cannot fork OpenCode session ... while it is still working" #24549 is a first-send race ("Cannot fork OpenCode session ... while it is still working") after an immediate fork after Stop; here the parent session is deleted, so the failure is permanent and affects every send.
• [Bug]: V2 run stays starting forever after provider-turn.start exhausts its retries — no Stop button, settle refused, only Delete clears it (Pi provider, desktop) #13392 is about a run wedged forever in starting after retries exhaust; here runs do settle as failed. The core issue is forkThread referencing a deleted native session and the resulting error being opaque.

Workaround

Open a brand-new conversation (not forked) — the fork chain is permanently wedged. I verified a non-forked session works fine.

Impact

Major degradation or frequent failure — the wedged fork is permanently unusable, and the only UI signal is an opaque error that gives no indication of what was lost or how to recover.