Priority: P1 — ambiguous-outcome class at the TollGate layer. Independent of gonuts fixes. #498

Priority: P1 — ambiguous-outcome class at the TollGate layer. Independent of gonuts fixes.

Problem

PurchaseSession wraps Receive in a 30s timeout, but the goroutine keeps running. When Receive completes after the timeout response was sent: funds land in the operator wallet, no session is granted, no record exists, and the customer was told "timed out, try again" — so they pay again. Duplicate value consumed for one session; every timeout has this tail risk.

Why it matters

Timeouts are routine (mobile-network mints). The current code converts each one into a potential silent confiscation with a lying error message. Same family as #403 but via the timeout path, and invisible in logs beyond a Receive-completed line nobody correlates.

Current behavior (source refs)

• src/merchant/merchant.go:506-538 — goroutine + select timeout; on timeout the notice returns immediately, goroutine abandoned.
• src/merchant/merchant.go:519-529 — late result (success or error) is logged and dropped.
• No pending-payment record anywhere (sessions are created only post-timeout-window).

Desired invariant

No Receive outcome is discarded: a late success is reconciled into a granted session (or refund) durably; a late failure clears the pending record; the customer-visible timeout message states that the payment may still complete and how to check (GET /usage).

Proposed scope

1. Durable pending-payment record keyed by token Ys hash, written before launching Receive (this is also the idempotency key — coordinate with the payment-saga design for Rust parity, Rust issues Refs/heads/x1860 #5/Build/Deployment improvements #6).
2. Late-completion handler: on late success → same grant path as normal completion (session + gate + record COMPLETE); on late failure → record FAILED.
3. Startup + periodic reconciliation: records in RECEIVE state older than timeout → query mint proof state (NUT-07) → resolve.
4. Timeout notice copy updated to reflect "may complete; check usage" (wire-compatible text change only).

Areas / files

src/merchant/merchant.go, new small store (JSONL or bbolt sub-bucket; flash-aware), startup reconciliation in merchant init.

Acceptance criteria

• Fault test: Receive completes at t=35s, timeout returned at t=30s → session granted at t=35s, /usage reflects it, record COMPLETE.
• Kill between receive-start and completion → restart reconciliation resolves by mint state.

Required tests

• Unit: late-completion grant path; reconciliation decision table.
• Integration (cloud-lab): slow-mint proxy lane.

Failure-injection tests

• Proxy delays swap response 35s (payment completes late).
• Proxy drops response entirely; mint did consume inputs (mint-side state says spent) → reconciliation grants session.

Compatibility

Notice text change only.

Dependencies

Conceptually pairs with the Rust payment-saga issue (Amperstrand/tollgate-module-basic-rust#5) — implement to the same state names for test parity.

Out of scope

• Refund issuance on late success + unreachable client (session grant suffices; refund policy lives in Payment consumed with no session when gate-open fails after successful Receive (no refund path) #403's resolution).