Tie active-run liveness to a single write instead of two independent ones - #404

Routing every non-"running" run.json write through finalizeRunState
made the terminal status itself the signal that the run had ended,
and so cleared the active-run handle. Session rotation (/clear,
/new) breaks that equivalence: it persists a terminal "done" for
the outgoing session while the process keeps running under a fresh
session id. Clearing liveness there left getActiveRun() null for
the rest of the process, so a crash after the first rotation never
wrote a terminal record and the session read as "running" forever.

Why a write happens is now explicit (SnapshotKind: progress,
session-rotation, run-end) instead of inferred from what it writes.
Only run-end clears the handle; persistRunSnapshot cannot request
it, since everything routed there happens while the process is
still alive.

Also drops the deleted `active` field from the crash fixture, which
sits outside tsconfig's include and so escaped typecheck.

The existing rotation tests covered clearsActiveRun as a pure
function and confirmed a handle survives a rotation write, but
nothing exercised a crash actually occurring afterward. Extend
the crash fixture to optionally rotate the session first, through
the same clearsActiveRun dispatch runner.ts uses, then crash and
assert the crashed record lands under the post-rotation session.

The prior comment only noted that finalizeRunState's own clear
becomes a no-op repeat, which reads as an argument for deleting
the early call rather than keeping it. It is not redundant: index.ts
installs its own crash listeners that read the handle directly
and would otherwise race a competing write during the awaits here.

Document that this is a second terminal write path alongside
finalizeRunState, kept apart because its only callers are the
process-level crash and signal handlers in index.ts, which cannot
afford to wait on saveState's per-session write chain during exit.

Deleted along with the standalone active-run clear when that call
site was folded into finalizeRunState's write, but the dispose
host has no on-disk write to piggyback on, so it never got a
replacement. Every normal run was leaving the dispose host
pointing at a torn-down closure that a later signal could still
invoke. Restored to mirror finalizeOnCrash, matching active-host.ts's
stated contract of clearing on either path.

RunStateHandle dropped its own active flag in favor of handle
presence as the sole liveness signal, but this fixture still set
it. tsconfig excludes tests/ from typecheck, so nothing caught
the stale field and the setter silently ignored the excess
property.

The existing crash-after-rotation test only covers a crash
arriving before any terminal write starts, so it stayed green
even with the run-end handle-clearing regression present. This
test parks the run-end write mid-flight and fires an unrelated
uncaughtException during that window, asserting the outcome is
never "crashed" — pinning the fix that moved finalizeRunState's
clear ahead of its own write.

saveCrashState requires markCrashed() first so chained saveState renames cannot clobber the terminal write. handleFatal already did this for uncaughtException; SIGINT/SIGTERM/SIGHUP called saveCrashState without the fence. Flip the flag before the signal write, and park stragglers in the signal fixture so the integration test pins it.