[1amKhush]

Closes #107.

Summary

Prevent repeated wallet actions and retries after a payment request has completed or been cancelled.

• Validate offers, configuration, and callback functions before wallet work; preserve opaque custom PMI identifiers.
• Enforce per-invocation amount, attempt, and deadline limits across replacement offers.
• Deduplicate attempts, pin in-flight/unknown outcomes, and evict handled/declined identities least recently used first when needed.
• Cancel retries and fence awaited callbacks on completion, cancellation, deadline, and close.
• Preserve typed request identity and enforce deliverable Nostr retries.

Validation and limits

• Fresh full concurrent suite: 742 passed, 5 live-wallet tests skipped, 0 failures.
• Focused coverage exercises request generations, cancellation, limits, capacity pressure, and encrypted payment flows.
• No storage backend or storage dependency is introduced. Server state and result recovery are handled by Feat/payment state durability #110 and Fix/payment settlement delivery #112.
• Advertised amount limits do not replace wallet-side validation of the payment payload. Uncertain attempts remain blocked pending reconciliation.

This storage cleanup does not change the reviewed #108 code. No live-wallet settlement runs were performed.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[ContextVM-org]

Great work — thorough fix for #107. Verified locally: all suites pass, typecheck/lint clean, and we confirmed the regression coverage genuinely reproduces the bugs (22/25 reliability tests fail on the pre-PR baseline). The synchronous find → approve → reserve window, abort-driven unknown resolution, and generation-fenced callbacks are exactly right; net source growth is only ~+71 lines with the module split done well.

Request changes on 1 and 2; 3–4 should be addressed or ticketed before release:

1. Attempt history: replace refuse-at-capacity with LRU + pinning (client-payment-attempts.ts)
The never-evict policy means a successful long-lived client hits payment_attempt_capacity after 1000 payments and can never pay again — recovery requires recreating the whole transport. Instead: pin in_flight/unknown entries (never silently payable again), evict handled/declined oldest-first under pressure (same LruCache ordered-scan pattern as ClientPaymentLifecycle), and keep the capacity refusal only when unresolved pins saturate — consistent with the server's pending-store precedent, and honest: "too many unresolved payments" is exactly when refusing is correct. unknown-unpinning is also the natural seam for the settlement-reconciliation PR.

2. PMI validation: match the server, don't exceed it (client-payment-validation.ts)
The /^[a-z0-9-]+$/ regex enforces a rule nothing else in the protocol enforces — the server validates processor PMIs not at all — and it already forced our own fixtures to rename (pmi:A → pmi-a). Relax pmiSchema to z.string().min(1) in all three usages (offer schema, handlers config, maxAmountByPmi keys); keep the amount/pay_req/ttl guards (those protect money, not identity matching). Flip the two PMI-rejection tests, add one interop test with a non-kebab PMI. If we ever want W3C-shape enforcement, it lands server-side first and the client mirrors it.

3. Payment flows went from well-logged to silent (client-payments.ts — logger used once)
The old code logged offer receipt, dedup hits, handler invocation, and retry scheduling; the rewrite kept only the duplicate-PMI warning. When a production request fails with payment_outcome_unknown or payment_limit_exceeded, support now has zero trail — on a money path. Restore a handful of debug/info logs at the key transitions (offer accepted vs deduped, limit refusal, retry scheduled, capacity refusal, unknown outcomes).

4. Client-facing docs don't cover the new API
limits, maxTrackedPaymentAttempts, and the new abortSignal contract on PaymentHandlerRequest (handlers should check it before wallet actions) exist only in JSDoc. Needs a section in the client payments how-to (docs submodule — fine as a follow-up, but please ticket it).

5. Minor: validateClientPaymentOptions doesn't check that onPaymentRequired/paymentPolicy are functions — a typo'd config passes validation and explodes inside the payment flow. Two .refine lines.