Keep the active database small by moving archived conversations into compressed storage

[Quicksaver]

Problem

Archiving hides a conversation but leaves its full history and attachments in the active database, so disk usage only grows. #6897 shows where this ends up (a 3.7 GiB database contributing to out-of-memory crashes during loading). Today the only way to reclaim space is permanent deletion (#6927).

Proposal

Make archiving also a storage operation:

• When a conversation is archived, its history and attachments move into compressed chunks in a separate archivev2.sqlite. Only a lightweight placeholder stays in the active database (title, pin state, linked PRs and lifecycle events), so Archive lists it as before.
• Archived conversations stay readable: opening one restores it first, and it moves back to compressed storage a couple of minutes later. Unarchiving restores it for good, and the compressed copy is only removed after the restore succeeds.
• A conversation stays uncompressed while something still depends on it: an unfinished run, a fork of it, or a running parent of a subagent conversation.
• Interrupted archive, restore and delete work resumes after a restart. Permanent deletion removes both copies.

Interactive demo: https://quicksaver-piz.vercel.app/t3code/conversation-data-savings
Earlier implementation (closed pending this discussion, since rebuilt on the V2 orchestrator): #12702

Decisions I'd like maintainer sign-off on

1. Existing archives:
   • (my vote) move them automatically after upgrading, then compact the active database once and switch it to incremental vacuum so later moves reclaim space in small steps?
   • or only when the user opts in, e.g. a button in Settings → Storage next to the existing cleanup options?
   • or a compromise: conversations archived after the update move automatically, while existing archives move only when the user opts in.
2. Conversations from before V2: upgraded databases keep the copied V1 tables as the source for importing transcripts. Archiving imports a conversation's transcript first and then moves its V1 rows into compressed storage with everything else, so pre-V2 conversations shrink the active database too. That makes cold storage a second reader of the V1 tables beside the legacy importer (one more entry in V1ImportBoundary.test.ts's allowlist). Is that acceptable to you?
3. What's kept: provider logs are deleted on archive rather than stored (terminal history is already deleted on archive). I think that's acceptable given what they're for, but compressing and keeping them is easy if you'd prefer.
4. Downgrades: an older version without cold storage can't read archived history, so conversations need to be unarchived before downgrading. Would documenting that restriction be enough, or do you want a different safeguard?

Out of scope

Automatic retention or expiry policies and checkpoint ref pruning (#13263). Client changes are limited to what cold storage needs: web and mobile stop caching archived conversations, and Archive shows a row as busy while its restore runs.

Contribution

• I would be open to helping implement this.

If this direction and scope work for you, I'll open a fresh PR scoped to whatever we agree on.