tracking(storage): task storage visibility, reclamation and scoped cleanup #5825

Step 1 of the task lifecycle plan agreed in #5776. It makes local storage visible, reclaims space that deletion already frees logically, and lets users clean up archived tasks by scope. It adds no automatic archiving or deletion; those are later, opt-in steps tracked in #5776. The Host computes and executes; Desktop only presents.

Baseline: main@0323714.

Current state

• Nothing reports how much space Maka uses, or which tasks use it.
• runtime.sqlite never shrinks.
  • It is WAL with auto_vacuum=NONE (sqlite-runtime-schema.ts).
  • Nothing calls wal_checkpoint, sets journal_size_limit, or runs VACUUM.
  • Deleted sessions leave free pages that SQLite reuses but never returns to the OS.
• context-offload.sqlite is set up for reclamation but never reclaims.
  • It is created with auto_vacuum=INCREMENTAL (sqlite-context-offload-schema.ts).
  • No code runs incremental_vacuum.
• Sessions have no archive time. session_metadata and SessionHeader have no archive time, and committed_at is overwritten on every metadata update, so it can't serve as one.
• "Delete all archived" runs in the renderer.
  • It calls session.remove once per session, serially (session-row-actions.ts).
  • Its confirmation shows a count, not a preview of what will be removed.
• fix(desktop): managed artifact previews outlive deletion and share one global quota #5341 is an in-memory preview lease that outlives deletion, not disk residue. fix(desktop): invalidate artifact previews after deletion #5394 fixes it at the Host retirement hook, and this issue depends on that fix rather than redoing it.

Plan: three PRs, each usable on its own

M1: storage visibility (read-only)

• New Host query storage.usage.query, query mode, Ready only.
  • Totals by kind: database, transcript, artifacts, context_offload, worktrees (count only), memory, usage_history and other.
  • The kind set is open for extension, for example the checkpoint store in feat(runtime-host): publish verified local session checkpoints #5605.
  • It also reports reclaimable free pages (freelist_count * page_size).
• Per-task sizes are computed on demand for a bounded list of session IDs (the visible page) and cached in memory.
  • There are no triggers or write-path counters, so nothing adds to the write amplification tracking(perf): bound storage and protocol read/write amplification #5038 is bounding.
  • Context-offload sizes per session are logical (blobs are deduplicated), and the UI says so.
• Desktop presents the results.
  • The Data page gets a "Storage" group with a breakdown and the reclaimable space.
  • The Tasks page shows a size on each row.
• Epoch bump.

M2: reclamation

• A bounded incremental_vacuum lane for context-offload.sqlite in the existing HostStorageMaintenance loop.
• runtime.sqlite conversion to auto_vacuum=INCREMENTAL. It needs one full VACUUM, which needs roughly 2x the database size in free disk, so it runs only on explicit user request ("Compact database"). The Host persists the request and runs it at the next start, before Ready, next to migrations, after a free-disk check.
• After conversion, bounded incremental vacuum plus a passive checkpoint run in the maintenance loop.
• The Data page reports what was actually freed.
• Epoch bump.

M3: scoped cleanup

• Durable archived_at.
  • It is set when a session is archived and cleared when it is restored.
  • It is projected into the session catalog.
  • Sessions archived before the field exists have NULL, show "archive time unknown", and are excluded from age filters.
• session.remove.preview takes a list of sessions and reports tasks, child tasks, bytes and worktrees that would be removed.
• The Tasks page adds filters for "archived more than N days" and project. The confirmation lists the preview. Execution keeps using session.remove.
• Epoch bump.

Questions for maintainers

1. Is the explicit-request, pre-Ready conversion of runtime.sqlite acceptable? The alternative is to only report the reclaimable space and never convert.
2. Should archived_at land as a small standalone PR first, since step 2 (retention) reuses it?
3. Should bulk delete become a Host-side batch command (possibly together with fix(storage): batch retired Session artifact cleanup #4984), or stay a renderer loop over session.remove?

Risks

• Protocol compatibility. Each milestone bumps the compatibility epoch.
• Overlapping changes. It touches the same files as fix(desktop): invalidate artifact previews after deletion #5394 and fix(storage): batch retired Session artifact cleanup #4984 (retirement coordinator, artifact store).
• Blocking the Host. node:sqlite is synchronous, so vacuum steps must stay small to avoid blocking the Host event loop.
• Retained usage history. It is deliberately kept when sessions are deleted (usage_model_call_attempts), so the database may stay larger than users expect. The UI should call this out.

Refs #5776, #5341, #5394, #5038, #4984, #5605.