Wallet subaddress creation with retry recovery

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