[1amKhush]

Closes #107

Summary

Repeated offers and delayed callbacks could repeat wallet work or retry completed requests.

• Validate payment offers, options, and configuration before wallet callbacks.
• Retain payment-attempt outcomes and add per-invocation amount, attempt, and deadline limits.
• Cancel retries and fence callbacks on completion, cancellation, or close.
• Preserve request identity and enforce deliverable Nostr retries.
• Add regression coverage for request generations and both encryption modes.

Validation

• Full concurrent suite: 693 passed, 5 live-wallet tests skipped, 0 failures.
• Typecheck, lint, build, and export checks passed.
• 100 focused tests passed; 19 regression cases reproduced failures on the original baseline.

Notes

• Amount limits apply to advertised amounts; wallet handlers must verify payment payloads.
• Attempt history is bounded and refuses new payments at capacity.
• Full browser bundling encounters a pre-existing applesauce-relay resolution error; helper bundles and the wrapper with that dependency externalized passed.

[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.