fix(checkpoint): don't count a timed-out writer wait as a writer failure

[wqymi]

Problem

waitForWriter bounds the writer's Deferred at 300s and maps the expiry to {status:"failure"} (packages/opencode/src/session/checkpoint.ts:989-993 on main).

That expiry does not cancel the writer. The settle watcher that owns the watermark advance awaits the same Deferred with no bound (checkpoint.ts:911-921), so a slow-but-successful writer still advances last_checkpoint_message_id after the bounded wait gave up.

So the prune retry watcher (prune.ts:312-337) books a working writer as broken:

• writerFailures ticks
• the session's crossed / maxCrossed thresholds are cleared → checkpoint writer failed — cleared thresholds for retry
• after MAX_WRITER_FAILURES such waits → checkpoint writer gave up after max consecutive failures, and the session stops being checkpointed even though every writer actually succeeded

Losing checkpoint coverage also degrades /rebuild: the span it can release is exactly the span the checkpoint covers.

Evidence (live TUI, dev build)

Real run on mimo-v2.5, checkpoint writer on the parent's model:

event	timestamp
threshold=60000 currentTokens=112596 → writer spawned	10:47:07
checkpoint writer failed — cleared thresholds for retry (attempt=1)	10:52:07 (exactly +300s)
same writer settles successfully, watermark advances msg1 → msg4	shortly after

Reproduced twice in a single session. The +300s alignment is exact — it is the wait bound expiring, not a writer error.

Fix

Return a distinct "timeout" outcome instead of "failure".

• prune.ts's existing if (result !== "failure") return guard then skips the counter and leaves thresholds untouched — no prune logic change needed.
• /rebuild is unaffected — and more strongly than an earlier revision of this description claimed. That revision cited a case-2 if (writerOutcome !== "success") bail at prompt.ts:4073-4082. No such code exists: git grep writerOutcome has zero hits repo-wide, and prompt.ts:4073-4082 is actor-notification rendering. The real shared path is rebuildFromCheckpoint (prompt.ts:398-430), used by both the automatic overflow path and manual /rebuild, and it never consults the writer outcome at all — it gates on hasCheckpoint + lastBoundary and deliberately does not block on an in-flight writer (see its own comment at prompt.ts:394-397). Changing the outcome value therefore cannot affect it.
• Retrying while the writer is still in flight was already a no-op: isWriterRunning short-circuits new threshold triggers, so nothing is lost by not counting.

Test

New test/session/checkpoint-writer-wait-timeout.test.ts uses TestClock to drive past the 5-minute bound with the writer's Deferred still unresolved.

Verified it is a real regression test — with the source fix reverted it fails with Expected: "timeout" / Received: "failure".

• bun run typecheck → exit 0
• focused suites (drain, prune, prune-skip-system, watermark-transactional, thresholds, new test) → 41 pass / 0 fail
• full test/session/ → 821 pass / 1 flaky fail that also passes on re-run and is unrelated to this change

Notes

An accidental benefit was removed along with the bug

Stating the trade honestly: on main, the mistaken timeout → failure mapping cleared crossed and maxCrossed (prune.ts:325-326). That had a beneficial side effect nobody designed — after a slow writer finally settled, the threshold re-fired. This PR removes that re-fire together with the false failure.

Mitigation: at the max threshold maxCrossed now stays set, so prompt.ts:3308-3314 still reaches rebuildFromCheckpoint, which calls prune.resetThresholds when it succeeds (prompt.ts:428) and re-arms the thresholds. Checkpointing is therefore not permanently stalled.

Follow-up

Two gaps this PR left behind are fixed in #1945: hitting the bound became completely silent (no log from either layer), and a writer that genuinely fails — or succeeds — past 300s had its real outcome booked nowhere, since prune's watcher returned on "timeout" and never re-awaited.

Independent of #1752 — the defect is present on main and this PR is deliberately not bundled into it.

Two related issues found during the same investigation are not addressed here (they need their own discussion):

1. Coverage pinning — thresholds fire mid-turn, but computeBoundary anchors on the last finished assistant and returns msgs[0] when there is none. A token blowup inside the first assistant turn pins coveredUpTo to message 1, so a full 5-minute writer run covers exactly one message.
2. Writer wall-clock — the writer inherits the parent's model (no model field on the checkpoint-writer agent) and needs ~13 sequential LLM round-trips (~20-25s each) to read prior checkpoint/memory and write its 3-4 files, which is what puts it near the 300s line in the first place.