Wallet subaddress creation with retry recovery

docs/custodial-market-design.md

@@ -19,7 +19,7 @@ The operator has authorized proceeding with implementation instead of the previo
 
 **Financial storage update:** [ADR 003](postgres-financial-storage.md) selects PostgreSQL and records the integrated asynchronous custody backend, restricted runtime/schema roles, deferred accounting constraints, explicit SQLite freeze/import, and full dump/restore rehearsal. SQLite remains an opt-in-compatible local sandbox default, not an automatic fallback. Real custody and production operating acceptance remain blocked.
 
-**Read-only Monero observation and allocation-registry groundwork:** [server/market/monero-observer.ts](../server/market/monero-observer.ts) defines a narrow mainnet wallet-RPC client for mainnet primary-address verification and bounded incoming-transfer scans. It requires explicit opt-in and a protected external config file, uses authenticated requests with strict HTTPS/literal-loopback-only HTTP, no redirects, bounded response/deadline, JSON-RPC request-ID validation and lossless JSON integer handling. Each observed transfer includes its validated destination address. It exposes no subaddress creation, credit posting, transfer construction, relay, sweep or withdrawal operation and is not wired into server startup/routes. [server/market/monero-observation-store.ts](../server/market/monero-observation-store.ts) persists scan manifests, exact incoming-transfer observations, cursor progress and append-only seen/changed/not-seen/reappeared events. **PostgreSQL schema v3** adds [server/market/monero-deposit-allocation-store.ts](../server/market/monero-deposit-allocation-store.ts), which can durably reserve a unique subaddress index for a beneficiary before a future wallet side effect and register a validated mainnet subaddress once. Reservations and beneficiary/index bindings cannot be deleted or reassigned; a registered address cannot be replaced. The registry is currently unreachable to both the custody API and observer roles, and the store is not wired to startup, routes, UI or wallet RPC. A wallet-generation UUID/fingerprint supplied to this groundwork is not proof of wallet ownership. It does not solve wallet-RPC/database crash reconciliation or establish the pinned RPC's per-output identity model. Confirmation growth updates an observation projection without emitting an event every poll. A missing output is only a review signal; no automatic journal posting, debit, reversal or customer credit exists. Schema v1→v3 is an explicit additive migration, not an HTTP-runtime migration. The final disposable PostgreSQL suite passed **35/35**, covering v1/v2 upgrades, concurrent reservations across independent pools, idempotency, immutable registration, role isolation and zero journal postings. The offline suite passed **183/183**, and the test-target build succeeded. No wallet endpoint, credentials or funds were accessed. This is not a working deposit-address allocator, live deposit processor, or approved mainnet switch. The application only calls read methods, but operators must still use a restricted view-only wallet RPC instance/account; the code cannot prove credential scope.
+**Monero observation and deposit-address allocation groundwork:** [server/market/monero-observer.ts](../server/market/monero-observer.ts) keeps the existing observer client strictly read-only: mainnet wallet validation and bounded incoming scans, authenticated requests, strict HTTPS/literal-loopback-only HTTP, no redirects, bounded response/deadline, JSON-RPC ID validation and lossless integer handling. A separate, narrow `createMoneroDepositAddressRpc()` capability can inspect one indexed subaddress or request exactly one labeled subaddress; it exposes no transfer, relay, sweep or withdrawal operation. [server/market/monero-deposit-allocation-store.ts](../server/market/monero-deposit-allocation-store.ts) now combines the PostgreSQL v3 durable beneficiary/index reservation with this capability: it reserves first, serializes cooperating allocators per wallet/account, checks the exact reserved index, and recovers a lost `create_address` response by looking up a deterministic allocation label before retrying creation. Address registration is immutable and performed only after the wallet returns the expected index/address/label. If another wallet client consumes indexes outside this allocator, the operation fails for reconciliation rather than reassigning an address; the wallet RPC must therefore be dedicated to the allocator. A wallet-generation UUID/fingerprint supplied to this groundwork is not proof of wallet ownership, and the RPC/database crash window has only been fixture-tested. Neither client nor orchestration is wired to startup, routes, UI, deposit scans or financial posting. The registry remains inaccessible to both custody API and observer roles. Observation storage continues to record reorg/reappearance evidence only; no credit, debit, reversal or journal can be posted. Schema v1→v3 is explicit and additive. The test-target build succeeded; **184/184** offline tests and **35/35** disposable PostgreSQL tests passed, including a simulated create-success/response-loss/recovery cycle with no duplicate address creation or journal posting. No live wallet RPC, wallet credential or funds were used. This is not a public deposit allocator or live deposit processor; mainnet payments remain disabled.
 
 Validation: TypeScript/Vite build and 144 offline tests passed in the serial native-RandomX test run; the initial parallel run encountered a peer-gossip timeout. Browser smoke verified a disposable wallet's signed test credit, withdrawal hold and cancellation restoring the exact balance, plus a 390px viewport without horizontal overflow. No real funds were used. Tests and remaining acceptance gates are below; this is not launch readiness.
 

docs/production-plan.md

@@ -20,7 +20,7 @@ Status: active engineering plan; **not launch or payment authorization**. Update
 
 **Current design deliverable:** [custodial market design](custodial-market-design.md). Read the workstreams below with this update: pooled customer liabilities replace per-order incoming invoices and external sale payouts in the proposed architecture. Earlier trustless-first research gates are historical, not a prerequisite to investigating custody. Exact ledger, withdrawal, fee, custody/legal and host-attested NFT consensus rules still require approval and evidence; the existing mock domain cannot authorize real balance debits.
 
-**Read-only XMR groundwork:** a disabled-by-default Monero wallet-RPC observer client is implemented for mainnet address validation and bounded incoming scans. Explicit PostgreSQL v1→v3 migrations add durable scan cursors, exact observation records, append-only reorg/reappearance markers, and a private beneficiary-bound subaddress-index registry. The registry can reserve a never-reused index before a future wallet RPC side effect, then register a validated mainnet subaddress once. It is not wired to startup/routes/UI/RPC; existing custody and observer roles cannot read or write it. The registry does not prove wallet-generation identity, solve RPC/database crash recovery, or determine unique output identity. Observation records include validated destination addresses. Missing outputs create review evidence only; neither observer nor registry can post credits, reverse balances or spend. Verification passed: Docker test-target build; **183/183** offline tests; **35/35** disposable PostgreSQL integration tests, including v1/v2 upgrades, cross-pool concurrent index reservation, replay, immutable registration, least-privilege isolation and zero journal postings. No live RPC, wallet credential or funds were used. Remaining deposit milestone: reconcile reserved allocations against the pinned wallet RPC and backed-up wallet generation; establish stable per-output identity and canonical inclusion/lock/reorg semantics; then design exact idempotent journal crediting plus audited reversal/hold handling, controlled stagenet rehearsal, and independent accounting/security review before any real deposits.
+**Monero observation and allocation groundwork:** the disabled-by-default observer remains read-only. A separate narrow RPC capability can read one indexed subaddress or create exactly one labeled subaddress; the internal allocator durably reserves the beneficiary/index first, serializes cooperating allocations, and recovers a create-success/lost-response case by checking the stable label at the reserved index. It refuses mismatched indexes instead of silently binding them. It is not wired to startup/routes/UI/scans/financial posting, and the registry remains inaccessible to custody API and observer roles. Its wallet-generation identity is unverified; recovery was tested with fixtures, not a real RPC/wallet; its assumptions require an allocator-exclusive wallet RPC and operational wallet/database reconciliation. The registry cannot establish unique output identity. Missing scans remain review evidence, not automatic balance changes. Verification passed: Docker test-target build; **184/184** offline tests; **35/35** disposable PostgreSQL tests, including v1/v2 migrations, independent-pool allocator concurrency, replay, immutable registration, least-privilege isolation, zero journal postings and simulated response-loss recovery without duplicate address creation. No live RPC, wallet credential or funds were used. Remaining deposit milestone: provision and verify an isolated wallet RPC instance and generation identity; reconcile reserved allocations and backed-up wallet state; establish stable per-output identity and canonical inclusion/lock/reorg semantics; then build exact idempotent journal crediting plus audited reversal/hold handling, stagenet rehearsal, and independent accounting/security review before any real deposits.
 
 ## 1A. MVP release boundary — proposed safe first production-hosted release