fix(runtime-host): defer conversation-copy discards to post-ready maintenance

[BigDataDZ]

Summary

Startup recovery used to await the physical sidecar purge of preparing conversation copies before the Host could publish Ready. The purge resolves artifact paths across the whole artifact store, so a workspace with a large accumulated store paid an O(all files) syscall sweep on every Host start and blocked readiness for minutes (profile and repro in #4027).

Recovery now only queues the copies it decided to discard:

• The durable headers stay the authority. An entry that never drains (crash before Ready) is re-derived by the next recovery pass, and every reader already treats a preparing copy as inert (root turns reject it, retirement skips it), so a copy visibly preparing for a few extra seconds post-Ready is a state the system already supports.
• Queued discards drain one admission-leased discard at a time through a new HostStorageMaintenance lane (deferred session discard), reusing the existing bounded-lane pattern (start after Ready, 100 ms active pacing, exponential backoff, drain/close shutdown semantics).
• The drain re-reads the header under the Session admission lease, so a copy committed or discarded in the meantime wins over the stale recovery snapshot, and a revision that admitted its first turn in between is committed instead of discarded (same rule as recovery).

This is the readiness half of #4027. The O(store) guard scan inside preparePurgePathsUnlocked itself (the other half) is intentionally untouched and can follow separately.

Refs #4027

Verification

• tsc --noEmit clean in @maka/runtime-host; biome check clean on the five touched files.
• New lane test in storage-maintenance.test.ts: sweeps at the active pace while the queue reports work, idles once drained.
• Updated execution-composition.test.ts "optional context Store cannot open": recovery no longer attempts the purge (no cleanup diagnostic), the maintenance lane takes the queued discard after Ready and reports retries while this environment cannot complete the purge, and the header stays preparing.
• New composition test "deferred conversation-copy discards drain through post-ready maintenance": a preparing copy survives recover() untouched and is fully discarded by the lane after Ready.
• session-revision-two-client-uds, execution-host-recovery, host-kernel, and the full execution-composition suite were run locally on Windows. Three host-kernel failures and two execution-composition failures (WorkHub does not record resume..., production executor admission discovers...) reproduce identically on a clean main build on this machine and appear unrelated to this change. The full-composition run also showed the node process not exiting after all 46 tests reported, which also predates this branch. The husky pre-commit hook was bypassed (--no-verify) because it fails to spawn biome.cmd under Node 24 on Windows (EINVAL, scripts/biome-staged-check.mjs); the touched files pass biome check directly.

AI use

Select exactly one:

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

Tool(s) and scope: ZCode (GLM). Read the recovery/purge path and drafted the change and tests; the human contributor reviewed the approach, ran the verification locally, and owns the result. Commits carry Generated-by: ZCode.