Moved reconciliation row selection and order/listing status evaluation into the worker thread

docs/canonical-indexes.md

@@ -10,13 +10,13 @@ Status: implemented local infrastructure, **not full M2 acceptance or production
 - On first open, original blocks are replayed and independently proof/state validated before additive local index backfill. Later opens compare indexed block identity, ownership, transaction inclusion and event continuity/anchors to that validated chain. Inconsistent state fails closed; existing consensus version, genesis, signatures and free-transfer/trade rules are unchanged.
 - [Market reconciliation](../server/market/store.ts) uses indexed current delivery/ownership queries and a persisted `(stream ID, sequence, anchor)` checkpoint. Every observed disconnect of a previously completed order causes a durable review hold, even if delivery reappeared before polling. Review is never automatically repaid. Hold updates and checkpoint advancement commit together in the market database.
 - Order and listing review now uses stable-ID keyset batches capped at 32 rows each. A strict, durable job record stores stage, continuation ID, observed time, chain tip/revision, and the bounded canonical event page. Each batch commits row effects and its continuation atomically; the canonical event cursor advances only after both tables finish. A chain tip/revision change during a multi-batch scan rewinds the job and captures a fresh event page, preventing a mixed-view scan from being marked caught up. Completion checks the current event head so events appended during the scan remain behind the write fence.
-- While any job/event backlog exists, ordinary market mutations and time-dependent payout/expiry decisions stop; diagnostic/read access remains available. Requests advance one bounded slice, and an unref'd HTTP-lifecycle pump drains remaining work without depending on page loads. The production HTTP process enables a single persistent Node worker thread to own atomic batch writes and final checkpoint commits; the main thread retains the chain queries, per-row reconciliation decisions and event/revision fences. This reduces SQLite write/commit work on the request loop but is **not complete CPU isolation**. Worker failure leaves the durable job/cursor intact, fails closed, and requires retry/restart; there is no horizontal-worker safety claim.
+- While any job/event backlog exists, ordinary market mutations and time-dependent payout/expiry decisions stop; diagnostic/read access remains available. Requests advance one bounded slice, and an unref'd HTTP-lifecycle pump drains remaining work without depending on page loads. The production HTTP process enables a single persistent Node worker thread to select rows, evaluate order/listing transitions, and atomically persist row changes plus job progress. The main thread supplies only a bounded snapshot of the relevant canonical transaction/NFT/pending facts and retains event/revision fences. This moves the per-row JSON/status work off-loop, but fact collection and database-snapshot preparation still run on the main thread. Worker failure leaves the durable job/cursor intact, fails closed, and requires process restart to retry; there is no horizontal-worker safety claim.
 - Reconciliation restart, mid-job event append/reorg fencing, disconnect review, and injected SQLite batch/cursor failures are tested. A failed batch leaves both order effects and durable keyset progress unchanged; restart resumes committed work. Restore mismatch (different stream, different history anchor or a cursor ahead of the restored ledger) is refused rather than resetting the cursor. Restore the matching stopped-node ledger/market backup; any alternative recovery requires reviewed evidence, not deleting a checkpoint.
 - [HTTP NFT lookup and custody card checks](../server/testnet/http.ts) use the same index. Wallet deck pagination accepts an optional `tip` query; stale tips return 409. Existing callers without `tip` remain compatible. There is no new public event/admin endpoint, no payment observer and no NFT-lock signer.
 
 ## Tests and measurements
 
-The final Docker test-target build passed TypeScript/Vite compilation. All **175 offline tests passed, zero failures/skips**, including native RandomX multi-process HTTP/peer/restart and backup rehearsal. The focused market suite passed **24 tests**; the disposable PostgreSQL suite passed **31 tests** in the preceding integration run. New failure evidence includes:
+The final Docker test-target build passed TypeScript/Vite compilation. All **176 offline tests passed, zero failures/skips**, including native RandomX multi-process HTTP/peer/restart and backup rehearsal. The focused market suite passed **25 tests**; the disposable PostgreSQL suite passed **31 tests** in the preceding integration run. New failure evidence includes:
 
 - indexed ownership/sequence versus full replay for transfers, multi-card trades and forks;
 - append/disconnect/reconnect ordering, side-branch/mempool exclusion, bounded defensive-copy pages and durable restart;
@@ -27,7 +27,8 @@ The final Docker test-target build passed TypeScript/Vite compilation. All **175
 - 32-row order/listing keyset progress, restart continuation, and a new canonical event arriving during an in-flight job;
 - chain revision change fencing that resets continuation and refreshes the event page before the scan continues;
 - injected batch-write failure rolling back order effects and keyset progress, plus cursor-write failure rolling back checkpoint advancement while preserving committed review holds;
-- worker-owned batch/finalize transaction with injected failure, mutation fence and restart continuation;
+- worker-owned row evaluation/batch/finalize transaction with injected failure, mutation fence and restart continuation;
+- canonical event arrival during an in-flight worker batch forces a fresh bounded event page before the cursor reaches the new head;
 - numeric cursor reuse with a different historical hash rejected;
 - real HTTP NFT results and stale-tip deck pagination.
 
@@ -46,10 +47,10 @@ Observed in the development Docker environment:
 
 These numbers are a reproducible **baseline**, not acceptance SLOs: host CPU/storage and production concurrency were not selected, outputs include synthetic article payloads, warm caches apply, one transaction amortizes insertion fsync, and real validation/startup/HTTP/market workloads are excluded. They do not establish a supported production envelope.
 
-The synthetic market-journal harness [benchmark](../scripts/benchmark-market-reconciliation.ts), available as `npm run benchmark:market -- 10000 [terminal|confirmed-delivery] [worker]`, measures terminal and confirmed-delivery reconciliation in its own temporary SQLite directory. With synchronous 32-row commits, 10,000 terminal orders plus 10,000 listings took 2,549 ms (about 7,845 records/s; sampled event-loop-delay p95/max 14.97/48.99 ms). The confirmed-delivery path took 4,667 ms (about 4,286 records/s; 20.63/62.23 ms). With worker-owned commits, the terminal fixture took 2,782 ms (about 7,190 records/s; sampled event-loop-delay p95/max 11.17/16.11 ms), and confirmed delivery took 5,762 ms (about 3,471 records/s; 13.39/24.25 ms). Worker IPC/transaction cost increases elapsed time, while sampled maximum main-loop delay fell in these runs; measurements are noisy and not an SLO. Maximum sampled pass duration with the worker was 25.15 ms for confirmed delivery, since row evaluation and chain lookups remain on the main thread. Canonical transaction IDs are in-memory adapter fixtures, not validated Ledger evidence. These runs are not target-hardware capacity claims and exclude concurrent HTTP traffic, PostgreSQL, actual chain validation and adversarial workloads.
+The synthetic market-journal harness [benchmark](../scripts/benchmark-market-reconciliation.ts), available as `npm run benchmark:market -- 10000 [terminal|confirmed-delivery] [worker]`, measures terminal and confirmed-delivery reconciliation in its own temporary SQLite directory. With synchronous 32-row batches, 10,000 terminal orders plus 10,000 listings took 2,549 ms (about 7,845 records/s; sampled event-loop-delay p95/max 14.97/48.99 ms). The confirmed-delivery path took 7,609 ms (about 2,628 records/s; 25.36/95.68 ms). With worker-owned selection/evaluation/commits, the terminal fixture took 5,893 ms (about 3,394 records/s; sampled event-loop-delay p95/max 12.12/24.05 ms), and confirmed delivery took 5,939 ms (about 3,367 records/s; 12.02/20.38 ms). Worker IPC reduces sampled event-loop delay but costs elapsed time on simple terminal rows; the confirmed-delivery workload is faster in the worker run. Main-thread row-key/fact collection remains, and timings vary. Synchronous pass max was 95.35 ms; worker dispatch pass max was 31.29 ms for confirmed delivery. Delivery facts are in-memory adapter fixtures, not validated Ledger evidence. These runs are not target-hardware capacity claims and exclude concurrent HTTP traffic, PostgreSQL, actual chain validation and adversarial workloads.
 
 ## Remaining gates
 
-M2 still needs target-hardware/data/SLO decisions, populated long-journal/large-event benchmarks, HTTP load tests during worker commits, production financial database/schema and measured recovery/retention/storage growth. The worker moves writes/final commits off-loop, but row processing/chain reads remain on-loop; queue isolation, multi-process fencing and a demonstrated production throughput envelope remain open. Ledger PoW replay and DAG state memory still scale with retained history; indexed queries do not solve those costs. Startup validation checks undo-record counts but not every possible future undo mutation against a second reconstructed undo model; comprehensive corruption/fuzz coverage and independent review remain required.
+M2 still needs target-hardware/data/SLO decisions, populated long-journal/large-event benchmarks, HTTP load tests during worker activity, production financial database/schema and measured recovery/retention/storage growth. The worker removes most per-row evaluation from the event loop, but gathering row keys and chain facts remains on-loop; queue isolation, multi-process fencing and a demonstrated production throughput envelope remain open. Ledger PoW replay and DAG state memory still scale with retained history; indexed queries do not solve those costs. Startup validation checks undo-record counts but not every possible future undo mutation against a second reconstructed undo model; comprehensive corruption/fuzz coverage and independent review remain required.
 
 Custodial reservations still stop at `awaiting-lock`. This increment does **not** consume ordinary transfers as custodial settlement evidence: doing that would bypass the reviewed sale-lock/cancel protocol. Real Monero deposit/withdrawal integration, production treasury keys, host attestations and a reviewed versioned NFT lock/completion/cancellation specification remain blocked. No real funds, credentials, external processor or genesis change were used.

docs/production-plan.md

@@ -63,7 +63,7 @@ Acceptance: exact-amount property/boundary tests, versioned signature tests, zer
 
 Can run alongside P0/P1. Addresses SEC-01/SEC-06 rather than adding more fixed caps.
 
-**Implemented M2 increments, 2026-10-20–21:** [canonical indexes and durable market observation](canonical-indexes.md). Canonical ownership/transaction SQL indexes now serve NFT, deck, custody availability and mock-market queries; per-block undo and anchored connect/disconnect events commit with ledger updates. Market checkpoint/reorg holds persist atomically and bounded catch-up blocks new mutations. Order/listing reconciliation advances in durable, stable-ID keyset batches of at most 32 records per table, resumes after restart, and re-fences when the chain tip/revision changes. The HTTP process now uses a single worker thread for atomic batch writes and final cursor commits; main-thread chain reads and row evaluation remain. Final TypeScript/Vite build and **175 offline tests passed**; focused market tests passed 24/24; the disposable PostgreSQL suite passed 31/31 in the preceding integration run. Synthetic 10,000-order/listing tests showed worker-backed confirmed-delivery elapsed time 5,762 ms and sampled event-loop-delay p95/max 13.39/24.25 ms, versus 4,667 ms and 20.63/62.23 ms with main-thread commits. This suggests a responsiveness/throughput trade-off on this development host, not an SLO. Remaining: real concurrent HTTP load, further main-thread CPU isolation, multi-process fencing, target hardware/data, production financial storage/recovery, retained-DAG capacity and operator SLO decisions.
+**Implemented M2 increments, 2026-10-20–21:** [canonical indexes and durable market observation](canonical-indexes.md). Canonical ownership/transaction SQL indexes now serve NFT, deck, custody availability and mock-market queries; per-block undo and anchored connect/disconnect events commit with ledger updates. Market checkpoint/reorg holds persist atomically and bounded catch-up blocks new mutations. Order/listing reconciliation advances in durable, stable-ID keyset batches of at most 32 records per table, resumes after restart, and re-fences when the chain tip/revision changes. The HTTP process now uses a single worker thread to select/evaluate each bounded row batch and atomically persist it with cursor progress, using a bounded chain-fact snapshot supplied by the main thread. Final TypeScript/Vite build and **176 offline tests passed**; focused market tests passed 25/25; the disposable PostgreSQL suite passed 31/31. Synthetic 10,000-order/listing confirmed-delivery runs took 5,939 ms with worker evaluation (event-loop-delay p95/max 12.02/20.38 ms) versus 7,609 ms synchronously (25.36/95.68 ms) on the development host. This is local synthetic evidence, not an SLO. Main-thread key/fact collection, concurrent HTTP load, multi-process fencing, target hardware/data, production financial storage/recovery, retained-DAG capacity and operator SLO decisions remain open.
 
 **Next financial-storage increment:** [ADR 003 — PostgreSQL](postgres-financial-storage.md) selects and integrates the custody SQL backend with existing HTTP callers, exact constrained accounting, explicit migration/runtime roles, source-freezing SQLite import and dump/restore rehearsal. The adapter remains on the fictitious sandbox domain; it is not a production deposit/withdrawal worker. SQLite node-only backup deliberately refuses PostgreSQL-bound financial state. Production hardware/SLO tests, coordinated backup/PITR/failover, real payment schema/worker controls and independent review remain open, so this does not close M2/M4 or authorize funds.
 
@@ -72,7 +72,7 @@ Can run alongside P0/P1. Addresses SEC-01/SEC-06 rather than adding more fixed c
 **Deployment increment:** [persistent local custody stack](persistent-custody-sandbox.md) now starts PostgreSQL and the actual app together, with private TLS/SCRAM networking, separate owner/runtime roles, explicit migrations and scoped persistent credential/data volumes. A signed fictitious credit and custodian identity survived container/network removal and recreation; the server rejected plaintext authentication. Existing deployments and SQLite custody were not switched. Production certificate rotation, coordinated backup/restore and external operating review remain open; all XMR remains simulated.
 
 - Indexed canonical ownership, NFT/transfer lookup and paged wallet/explorer APIs: browser signing must not require loading all history. Tip-pinned queries detect reorgs and preserve complete ownership semantics.
-- Incremental market reconciliation from durable canonical/reorg events. **Local bounded implementation delivered:** rollback-safe canonical event pages, durable 32-row order/listing keyset jobs, tip/revision re-fencing, restart continuation, mutation fencing, and a single worker thread owning atomic batch writes/finalization. Regression tests cover reorgs, injected worker commit failures and restart recovery. **Still open:** move more row evaluation/chain lookup work off the request event loop, measure concurrent HTTP latency and queue lag, coordinate/fence processes, and establish throughput/overload/recovery limits at declared order/event volumes.
+- Incremental market reconciliation from durable canonical/reorg events. **Local bounded implementation delivered:** rollback-safe canonical event pages, durable 32-row order/listing keyset jobs, tip/revision re-fencing, restart continuation, mutation fencing, and a single worker thread that selects/evaluates batches and atomically commits them. Regression tests cover reorgs, injected worker commit failures and restart recovery. **Still open:** move bounded key/fact collection off the request event loop, measure concurrent HTTP latency and queue lag, coordinate/fence processes, and establish throughput/overload/recovery limits at declared order/event volumes.
 - A versioned production market/settlement schema with append-only financial events and balanced accounting entries for buyer liabilities, host revenue, author liabilities, seller liabilities, paid/refunded amounts and actual network fees. Derived views are rebuildable; financial history and idempotency keys are not discarded to reclaim space.
 - Durable inbox/outbox, processor attempts and reconciliation states; no network operation inside a long DB transaction. Store intent before external side effects; unknown POST outcomes stay quarantined until evidenced resolution. Per-market isolation, actor-scoped paged reads, queue/backpressure and tenant/global exposure budgets.
 - Database architecture ADR: retain a measured single-writer SQLite deployment if it meets declared limits, or choose a production DB/worker topology and supported migration. Do not claim horizontal safety merely by launching multiple workers against local state. Start with one authoritative writer per market.