fix(server): fail V2 runs when provider sessions cannot open

[pekth]

A provider session that rejects during V2 startup leaves the run in starting, so a delegated task continues to report running after the effect worker exhausts its retries. This occurred with a Grok ACP protocol startup failure in preview 0.0.43-preview.20260919.1974.

Persist a failed run, attempt, root node, and error item when session opening returns a typed failure. The existing current-attempt/status guard prevents stale failures from overwriting interruption; database write failures remain retryable. Pure interruption propagates unchanged.

This is a T3 Code lifecycle bug, not a Fleet configuration bug. The failing regression invokes ProviderTurnStartService directly. A rejected providerSessions.open exits before startRootRun and, on the original code, leaves the durable run in starting. No Fleet code or hook participates in that path.

Validation: the new regression failed against the original code, then all 9 focused ProviderTurnStartService tests passed. The existing SQL stale-start guard test passed. Server typecheck, scoped lint/type diagnostics, formatting, and diff checks passed. The running preview was not replaced, so this does not claim a successful Grok session on an installed candidate.

Targets the V2 branch tracked by #2829. The change handles session opening before startRootRun.

Models: GPT-5.6 Sol for implementation and independent review; GPT-6 Astra for controller verification. Harness: Codex through T3 Code preview.

[macroscopeapp]

Approvability

Verdict: Approved at 89bddb3

Macroscope's review found this PR approvable — This is a localized V2 startup bug fix that terminalizes runs when provider sessions fail to open, while preserving interruption, stale-run, retry, and successful-start behavior. The production change is self-contained and accompanied by targeted regression tests, with no schema, default, deployment, or static-analysis configuration impact.

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

[juliusmarminge]

Rebased onto t3code/codex-turn-mapping at 9d6feae1ff. The commit applied cleanly with no conflicts.

One follow-up commit on top (f780c2a84b): the new session-open failure branch rebuilt the same signal turn item, run.updated, run-attempt.updated and node.updated events (and the same writeIfRunCurrent guard) that the earlier sign-out / empty-compaction branch in ProviderTurnStartService.start already assembles. Pulled that into one local helper, settleRunBeforeStart, and call it from both places. Behavior is unchanged: the account path still stamps startedAt and appends its provider-thread.updated, and the session-open path still leaves startedAt null and emits no provider-thread event, which is what your regression asserts.

Verified in apps/server: vp test run src/orchestration-v2/ProviderTurnStartService.test.ts (9 passed, including the existing sign-out completed/failed cases and your new session-open case) and vpr typecheck (clean).

Nothing else changed.

Rebased and touched up by a maintainer's agent; a human will re-review.