Bound retained checkpoints, and stop reading every one to open a window

[VeryComplexAndLongName]

The extension had been taking many seconds to activate.

What was happening

.openspec-ui/checkpoints	531.6 MB in 29 files, 12–24 MB each
.openspec-ui/workbench-runs.json	42 KB

activate() awaits journal.load(), and load() read and JSON.parsed every one of those files, sequentially, before activation could finish.

checkpoint-storage-split moved the bytes out of the journal without removing the read. Its goal was that the journal stays small, and it does — load() then re-read every payload it had just stopped embedding. The journal is 42 KB and the load was half a gigabyte.

Nothing bounded the growth either. write() retained a checkpoint for any process inside maxProcesses (default 100), and pruneCheckpointFiles only deletes files nothing references — so with every session referenced it never had anything to delete. At ~20 MB per apply stage that is two gigabytes read at every window open.

What changed

• load() returns references plus a loadCheckpoint() reader.
• New maxCheckpointSessions, default 10, separate from maxProcesses. Measured, not picked: at 12–24 MB each that is ~150–200 MB and about half a day of this repository's activity.
• .openspec-ui excluded from the editor's file watcher — which had no watcherExclude entry at all — and from search.

Retention is by recency, never by state

Dropping terminal runs was the first instinct and it is wrong:

canRollback: Boolean(checkpoint?.after && checkpoint.delta
  && ["completed", "failed", "interrupted"].includes(process.state))

A finished run is precisely one the recovery view still offers to roll back. That mistake was made on the real directory before it was caught — pruning by state freed 502.8 MB and with it the rollback of 24 past runs. Harmless, because all of them were merged; instructive, because the reasoning behind it was contradicted by the code.

Half the laziness is deliberately not done

WorkbenchRecoveryService.details() is synchronous and answers delta, coverage and canRollback out of the checkpoint. Deferring the read there means making it async and taking that through the transport protocol and both surfaces.

So both consumers still resolve eagerly through loadCheckpoint() — bounded now by retention rather than unbounded. The remaining half (persist the small parts in the reference; read the large after snapshot only on rollback) is task 2.4, and is named in a comment at both call sites rather than left to be rediscovered.

A regression I introduced, caught by the tests

Sorting the persisted session list newest-first broke rollbackChange, which reads sessions back in stored order to find the earliest state to restore to — a reordered list turned a rollback into a conflict. Selection and ordering are now separate: chosen by recency, written in the caller's order.

Test plan

• npm run typecheck — clean
• packages/extension — green
• packages/core — 515/516; the one failure is git.push.test.ts, already tracked as core-test-worker-contention and untouched here
• openspec change validate --strict — valid
• npm run lint:english — passed
• CI green

🤖 Generated with Claude Code