fix(orch): prevent lost updates from concurrent store operations

[rudycelekli]

Concurrent operations on the same orch store handle can silently lose successful writes. In a filesystem reproduction, all 12 concurrent units.add calls resolved successfully while only one unit remained. The PID lock excludes other handles, but operations sharing the handle can still interleave their read/modify/write steps.

Queue complete operations per handle, including reads and initialization. A failed operation does not block later work. Closing rejects new operations, waits for accepted work and then releases the existing PID lock. Regenerate the Claude harness copies from the source.

Validation: the Store suite passes 19 tests and 83 assertions. Identical tests against main produce 15 passes and four regression failures. Coverage includes units, ledger, gates, standing orders, inbox ordering, read-after-write, rejected writes, close ordering and existing cross-handle lock controls. Three CLI tests were filtered because their dependency is unavailable; no installation or full CLI validation was performed. Harness generation and drift checks pass. AI-assisted implementation and testing.

---

Note

Medium Risk
Changes core orch store concurrency and close ordering; incorrect queuing could still corrupt on-disk state or deadlock, but behavior is covered by new regression tests.

Overview
Fixes lost updates when multiple async calls share one openStore handle: the PID lock only blocks other processes, not interleaved read/modify/write on the same handle.

store.ts builds the real implementation as an internal api, then returns a wrapper that enqueues every method (units, ledger, inbox, gates, frontier, standing, status, init) on a per-handle promise chain so operations run one at a time. Rejections do not stall the queue. close rejects new work with store is closed, drains queued work, then releases the lock.

orch.test.ts adds Store same-handle ordering tests for concurrent unit adds + read-after-write, parallel ledger/gate/standing updates, inbox push/drain/peek, duplicate-add rejection followed by a successful add, and close vs in-flight init/write.

^{Reviewed by Cursor Bugbot for commit 0fb2edf. Bugbot is set up for automated code reviews on this repo. Configure here.}