refactor(storage): centralize root writer lifecycle

[Colafornia]

Summary

Add a storage writer composition that owns the Runtime Host writer lifecycle.

The composition now:

• validates the root lease before opening writers
• permits only one active composition per root lease and rejects overlapping opens
• opens existing domain writers in one defined order
• closes opened writers in reverse order after partial initialization failures
• keeps the lease unavailable if any writer fails to close
• makes close() idempotent
• removes writer lifecycle management from Runtime Host domain coordinators

Domain writer interfaces, authorization checks, and persistence behavior remain unchanged. This PR does not introduce a repository framework or merge domain interfaces.

The Runtime Host still bootstraps runtime policy immediately after opening its stores and before opening the remaining writers.

Verification

• npm --workspace @maka/storage run typecheck — passed
• npm --workspace @maka/runtime-host run typecheck — passed
• targeted storage composition and usage-store tests — 12 passed
• Biome format check for changed files — passed
• git diff --check — passed
• full storage suite — not rerun after the review fixes; the earlier run passed 832 tests and had 3 unrelated environment or fixture failures

AI use

Select exactly one:

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

Tool(s) and scope: Codex implemented the storage writer lifecycle refactor, drafted its tests, and addressed code-review feedback. The human contributor reviewed the final diff and owns the decision to submit it. The commit carries a Generated-by: Codex trailer.

[Astro-Han]

Reviewed at 3f3dc4ab. The consolidation is the right move and the shape is good: one owner for writer open order, reverse-order rollback on partial failure, and a single storage.close() replacing twenty-odd individually-tracked let store: X | undefined variables and their hand-written cleanup ladder in execution-composition.ts. Removing 150 lines of that ladder is a genuine simplification, and the failure path is now correct where it previously depended on every future writer being remembered in three places.

I checked the two things most likely to break in a refactor like this and both are fine: execution.sessionStore.close() is the full teardown — closeExecutionStorePersistence closes runtimePersistence, agentRunStore, conversationOperationalStateStore, messageReceiptStore and the interaction-store facade — so closing only sessionStore is not a leak; and runtimePolicy / memoryBundle are the two writers passed without a close callback because they genuinely expose none. Closing all stores after every domain module has closed, rather than interleaved per module, is also an improvement: coordinators now reliably shut down before the stores they write to.

The architectural concern is ownership, and it is what all three inline findings share. This PR does not just centralize the lifecycle, it also makes the composition a process-wide singleton per lease — openStorageWriterComposition caches on the lease object and hands the same frozen object to every caller. Before this change, the execution stores were already lease-cached, but the other thirteen writers were not: two callers each got their own project-catalog writer, and one closing did not disturb the other. Now close() is an unconditional teardown of a shared object with no reference count, and the second holder's close() silently resolves to the first holder's memoized closeTask. The new test asserts first === second and then closes twice — which encodes the sharing but never exercises the hazard it creates.

That is worth deciding deliberately rather than inheriting: either the composition is genuinely a singleton whose lifetime the root owner controls (in which case close() should not be on the object every caller holds), or it is shared and needs a reference count. Today production reaches it through a single root owner so the window is narrow, but createExecutionRuntimeHostCompositionSource is a source — it can build a composition more than once over a process lifetime, and any overlap between one teardown and the next open lands exactly in that window.

Reviewed with Claude Opus as an analysis assistant. I verified the store close surfaces, the old and new cleanup paths, and the added test by reading source at this head; the race in the first finding is reasoned from the code path and not reproduced by execution.

[Astro-Han]

Re-reviewed at a9fd1a14. All four findings are fixed, and the author picked the stronger of the two options I offered rather than the cheaper one.

Replacing the per-lease cache and single-flight map with an activeCompositions WeakSet removes the sharing that caused three of the four findings at once:

• Handing out a closing composition — impossible now. The lease stays marked active until close() settles, so an overlapping open throws instead of adopting a dying composition. The new test pins exactly this: it rejects a second open while the first is alive, rejects again duringclose(), and then succeeds once the close resolves.
• Shared teardown with no reference count — moot, since two holders can no longer exist. This also removes the silent-no-op second close(), which was the part I liked least.
• Order-dependent afterRuntimePolicyOpened — moot for the same reason, and the doc comment was correctly rewritten from "runs only when this call starts a new composition" to what the hook now unconditionally does.
• Empty close: [] placeholders — removed from all three domain modules.

Choosing "one composition per lease, loudly enforced" over "shared with a reference count" is the right call: it makes the lifetime rule checkable at the boundary instead of distributed across holders, and the failure is an error at open rather than a use-after-close later. The duplicate activeCompositions.has check before and after assertStorageRootLease is not redundant in a way that matters — the pair is atomic because there is no await between the second check and add, and the early one just avoids paying for the lease assertion on a busy lease.

One thing worth confirming rather than a finding: this converts a previously silent situation into a hard throw. On main, two callers on one lease each opened their own writers; now the second gets Storage writer composition is already active for this lease. createExecutionRuntimeHostCompositionSource builds a composition per context and test-only/desktop-e2e-execution.ts builds one too — please confirm no path constructs two concurrently against a single owner's lease, because that now fails at startup instead of degrading. Failing loud is the right behaviour; I just want it to be a decision rather than a discovery.

Reviewed with Claude Opus as an analysis assistant; verified by reading the full new file, the rewritten test, and the diff against the head I previously reviewed. Nothing was executed.

[Astro-Han]

Approving at a9fd1a14. All four findings are resolved, and by the stronger route: one composition per lease, enforced at the boundary, with an overlapping open rejected until close() settles. That removes the shared-teardown and use-after-close hazards outright rather than papering over them. The one P3 left on the previous review — what a failed close should do to the lease — is a decision to record in a comment, not a blocker.

[Astro-Han]

Re-reviewed at 38b816c8 after the force-push dismissed my approval. The P3 from my previous review is fixed, and fixed as the decision I asked for rather than as a patch: .finally became .then, so a close that fails keeps the lease unavailable, with a comment on the line saying exactly why — a failed close may have left a writer handle open. That closes the double-open hazard.

Two things I checked because they follow from that change:

• Dropping the try/catch that deleted the lease on open failure is correct, not an omission. failOpen already routes through close(), so a successful rollback releases the lease and a failed one holds it — the old outer catch would have released unconditionally and contradicted the new policy.
• The cost is now explicit: a close failure makes that lease unusable for the rest of the process lifetime, recoverable only by restarting. That is the right side of the trade to land on, since the alternative silently opens the same SQLite files twice, and it is now stated in the code instead of implied.

The added test earns it — it forces a real close failure by closing the operational-state database underneath the composition, asserts close() rejects with an AggregateError, and then asserts the reopen is rejected. That is the assertion that would catch a future revert to .finally.

Approving. Reviewed with Claude Opus as an analysis assistant; verified by diffing both files against the head I previously approved. Nothing was executed.