fix(runtime-host): Host recovery decodes every Session's full history before readiness, breaching the 45s election deadline

[me2seeks]

What happened

Runtime Host startup recovery decodes the entire durable execution history of every recoverable Session before reporting readiness. On a long-lived workspace (~80 recoverable Sessions, ~500 runs, ~100k event/message rows in runtime.sqlite) recovery takes ~150s of mostly main-thread CPU, which breaches the client's default 45000ms election deadline: maka --resume <id> fails with "did not become ready before the startup deadline elapsed" (lastRegistration.state: "recovering", readyWaitFailed: 1) even though the Host is making progress. Retrying after the Host settles works.

This is the residual bottleneck after the artifact-store costs in #4027 are removed; CPU profile of a recovering Host (CDP Profiler on the main thread) shows:

• ~32% readSqliteAgentRunEvents (packages/storage/dist/agent-run-store.js)
• ~30% better-sqlite3 all() calls
• decodeStoredRuntimeEvent, GC pressure

Root causes in packages/runtime-host/src/server/hosted-execution-recovery.ts (prepareHostedExecutionRecovery):

1. Discarded per-run validation reads. For every Session, for every run, it awaits readEventsForRecovery + readRuntimeEvents and discards the results — a full decode of every event of every run, purely as a fail-closed consistency check.
2. Messages are decoded twice. listForRecovery() (packages/storage/src/session-store.ts) already calls readMessagesForRecovery per header and discards the result; prepareHostedExecutionRecovery then re-reads the same messages per Session.
3. The per-session loop is fully serial, though note better-sqlite3 all() and JSON decoding are synchronous main-thread work, so concurrency alone would not help — the fix has to reduce the amount of work, not interleave it.

Because admission/message repair decisions only involve Sessions with admissions, non-terminal runs, or pending closures, decoding the history of long-settled Sessions appears unnecessary for correctness — it is startup-time insurance with O(total history) cost paid on every Host start (upgrade, epoch cutover, crash recovery).

How to reproduce

1. Use a workspace with a large accumulated history (many recoverable Sessions and runs; here ~80 Sessions / ~500 runs / ~100k rows).
2. Restart the Runtime Host (upgrade or stop the previous one).
3. Run maka --resume <session-id> within the first ~2 minutes.
4. Observe the election deadline error while the Host is still recovering; Host main thread sits at ~50-70% CPU decoding SQLite rows.

Environment

• Commit: d27c02af1 (main)
• Node: 26.3.0
• OS: Linux
• Surface: Runtime Host / TUI

Logs, screenshots, or additional context

Election diagnostic from the client:

{"deadlineMs":45000,"elapsedMs":45008,"candidateLaunches":1,"sawEndpointConnected":true,
"observations":{"readyWaitFailed":1,"connected":1},
"lastRegistration":{"state":"recovering","lifecycleMode":"ephemeral"}}

Related: #4027 (artifact-store cold-start costs; fix in #4031).

Suggested directions (needs a design decision on the startup-validation contract):

• Scope recovery to Sessions that actually need it (admissions, non-terminal runs, pending closures) instead of every recoverable Session; or make full-history validation lazy/on-demand.
• Drop the discarded double read of Session messages (keep a single decode).
• Optionally surface recovery progress so waiting clients can extend their deadline adaptively instead of failing at 45s.

[me2seeks]

Working on a first, semantics-preserving step: prepareHostedExecutionRecovery currently triggers two full message decodes per Session — one discarded pre-read inside listForRecovery(), one explicit readMessagesForRecovery in the per-session loop. The facade already exposes listHeaders(), and all production callers of listForRecovery() only consume the headers, so the recovery coordinator can list headers directly and keep exactly one decode per Session (the fail-closed message validation still happens in the per-session read).

Skipping per-run validation reads for terminal runs (the dominant cost here) changes the startup-validation contract, so I am leaving that for maintainer discussion in this issue before sending a PR.

[me2seeks]

Measured end-to-end on the same long-lived workspace (~80 recoverable Sessions, ~500 runs — all terminal, ~100k event/message rows), cold Host start to interactive TUI:

Stage	Cold start
Before #4031 (artifact recovery storm + full validation decode)	10+ min
With #4031 only	~157 s
With #4031 + #4033	~135 s

Profiling during the remaining 135 s confirms the residual cost is the discarded per-run validation decode (readEventsForRecovery/readRuntimeEvents over every run), exactly the item flagged for a design decision above.

Two additional findings from the measurements:

1. recoverable does not exclude archived Sessions (sqliteRecoverableSessionRolePredicate is ordinary + coordination only), so archiving old Sessions does not reduce recovery work today.
2. MAKA_RUNTIME_HOST_ELECTION_DEADLINE_MS is capped at 120000 ms, below the measured 135 s recovery time — even the escape hatch cannot cover a cold start on this workspace until recovery gets cheaper.