bug(storage): context-offload page reclamation never retries an unfinished WAL checkpoint #6149

What happens

reclaimFreePages in packages/storage/src/sqlite-context-offload-store.ts (added in #5855) runs PRAGMA wal_checkpoint(PASSIVE) only in the call where incremental_vacuum reclaimed pages:

if (this.#readTransaction(() => this.#freelistPages()) === 0) {
  return { reclaimedPages: 0, hasMore: false };
}
// ...
if (result.reclaimedPages > 0) this.#database.exec('PRAGMA wal_checkpoint(PASSIVE)');

PASSIVE does not wait for readers. If another connection holds an older read snapshot while the last batch commits, the checkpoint stops early and the truncated pages stay in the WAL. The freelist is already empty at that point, so every later maintenance tick returns at the first check and never retries the checkpoint. The pages are reclaimed logically, but context-offload.sqlite does not shrink on disk until some unrelated write happens to trigger an autocheckpoint. On an idle install, that may never happen.

@Astro-Han reproduced the same pattern with real SQLite in the review of #6083, which copies this logic for runtime.sqlite: after 536 pages were drained with a reader pinned, the file stayed at 3,334,144 bytes; one extra PASSIVE checkpoint brought it to 1,138,688 bytes.

This is not data corruption: reads, the freelist accounting and quick_check are all correct. The problem is only that the disk space is not returned.

Expected

Once the freelist drains, a checkpoint that could not finish is retried later without blocking. The maintenance lane still never takes the write lock on an idle tick, never waits on readers, and never runs a full VACUUM.

Suggested fix

Read the row that wal_checkpoint(PASSIVE) returns (busy, log, checkpointed). If busy = 1 or checkpointed < log, keep an in-memory "checkpoint pending" flag. On the next tick, if the freelist is empty but the flag is set, run PASSIVE again outside any write transaction, and clear the flag once it completes. Return hasMore: false so the lane stays on its idle cadence instead of spinning while a reader holds its snapshot.

Add a regression test that holds a read transaction across the final batch, releases it, and asserts that the file shrinks on the next idle call.

Ideally runtime.sqlite (#6083) and context-offload share one small helper, so the two lanes do not drift apart. See my review on #6083.

Refs #5855, #6083, #6000