fix(core): resume sessions after restart

[kitlangton]

Addresses #35646

Summary

• durably record Session execution lifecycle outcomes
• recover Sessions whose latest execution was interrupted by server shutdown
• serialize startup recovery with the existing cross-process EffectFlock
• reuse existing stale-tool reconciliation so ambiguous side-effecting tools are failed rather than replayed

How it works

A recovering process acquires the global Session recovery lock before reading lifecycle state. It holds that lock while all interrupted Sessions resume. Other daemon candidates wait, then re-read lifecycle state after the first process has recorded session.execution.started or a terminal outcome, so they have nothing to resume. No new recovery table or migration is needed.

User interruptions, completed executions, failures, and unmatched execution starts are not resumed. Unexpected hard-process death still needs an explicit ownership/lease design because blindly resuming an unmatched start can duplicate provider work while another process remains alive.

Verification

• bun run test -- test/session-execution-local.test.ts test/util/effect-flock.test.ts
• bun typecheck in packages/core
• file-scoped Prettier and oxlint
• pre-push full repository typecheck: 31 packages passed

[kitlangton]

Closing this draft because startup event scanning and a long-held recovery lock are the wrong shape. #35826 establishes single managed-daemon ownership first; the follow-up recovery change will use a bounded pending-recoveries projection instead of scanning history.