feat(storage): reclaim the prepared-request captures already on disk

[Astro-Han]

Summary

#4722 stops producing prepared-request captures. This reclaims the ones already on disk. On my own 814 MB installation they are 772.7 MB — 87% of the Artifact population, and 99.4% of their bytes are re-serialized duplicates of messages already in the ledger.

A bounded background sweep drains them through the same purge-intent path a Session delete uses, then stops. It reclaims the files and the Artifact rows naming them — nothing else. The per-segment detail #4722 stopped writing sits in the AgentRun ledger, which is append-only by design, so those rows stay where they are and only new calls are cheaper.

#4722 has landed, so this now stands on its own: 4 commits on current main.

Refs #4037, #4704.

🔀 What this changes about deletion

flowchart TB
    subgraph BEFORE["until now"]
        direction LR
        P1["purgeSessionArtifacts"] --> B1["Artifact bytes"]
        P1 --> E1["events naming them"]
    end
    subgraph AFTER["this sweep"]
        direction LR
        P2["purgeRetiredCaptures"] --> B2["capture bytes"]
        E2["attempts naming them<br/>append-only, cannot be retracted"]
    end
    BEFORE -.-> R["⇒ a capture reference<br/>must tolerate a missing referent"]
    AFTER --> R

    classDef gone fill:#fcebeb,stroke:#e24b4a,color:#a32d2d
    classDef live fill:#e1f5ee,stroke:#1d9e75,color:#0f6e56
    classDef rule fill:#fff6e0,stroke:#d99a1f,color:#8a5f00
    class B1,E1,B2 gone
    class E2 live
    class R rule

Loading

Artifact bytes and the events naming them have always been removed together. This sweep is the first mechanism that removes bytes while the events referencing them live on, because the AgentRun ledger is append-only: a historical ModelCallAttempt keeps its captureArtifactId forever.

That is the review question — who reads a capture reference, and does it survive the referent being gone.

• captureArtifactId in a conversation copy was a required mapping. Once a capture was reclaimed, branching or copying any Session holding a historical model call threw Conversation copy is missing Artifact … and could never succeed again. The key now leaves with the bytes; the attempt still copies and still decodes.
• Every other Artifact reference in conversation-copy.ts — attachment refs, tool-result Artifacts, snapshot lists, linked children — still throws on a missing target, and should. The sweep filters on source === 'provider_request_capture', and none of those name that source.
• Decoding is untouched. captureArtifactId stays in the ModelCallAttempt schema and its validator: hasExactShape fails a whole record on an unknown key, so dropping the field would strand exactly the records this exists to free the bytes of.

Also removes the two capture decoders #4631 left behind in conversation-copy.ts when it retired both provider-request event types from the emitted catalogue — a copy no longer reaches either.

🧹 The sweep

starts	after openedArtifactStore.recover() — a write authority refuses every mutation until it has recovered
batch	256 Artifacts per pass, through the shared mutation queue
pause	max(250 ms, 3 × last batch) — a batch holds the writer lock and its cost rises with the store, so a fixed pause would not stay behind live turns
stops	when nothing is left, when the Runtime Host closes, or after one failed batch (logged once)

Each batch is durable on its own, so stopping only means the next one does not start; a later run continues from the residue.

✅ Verification

• format, lint clean. test:dist: @maka/storage 1,122, @maka/runtime 3,217, @maka/runtime-host 1,687, @maka/core 807 — 0 failures. typecheck also on @maka/desktop, @maka/ui, @maka/mcp, @maka/eval, maka-agent.
• The copy test fails without the fix — verified by putting rewriteOwnedArtifactId back: Error: Conversation copy is missing Artifact artifact-gone.
• Not run: full-repo suite, Playwright E2E. Nothing user-visible changes; the reclaimed Artifacts have had no reader since refactor: replace Headless with minimal Eval kernel #2605.

AI use

Select exactly one:

• No generative tool made a substantive contribution
• Generative tooling made a substantive contribution

Tool(s) and scope: Claude Code — traced the reference points, wrote the implementation and tests. Reviewed and verified by me.

Checklist

• Tests cover the change and fail without it
• Lint, format, typecheck and the affected suites pass locally

Does this PR entail a change in behavior?

• Yes — described under Summary above
• No