SIGN IN SIGN UP

fix: the hosted payer page refused every link and accused the merchant

Round 8's refusal treated a 404 from the invoice lookup as "your server says
it never issued this". A static host 404s every path it does not have, and the
page is published on GitHub Pages - so every legitimate payment link was
refused, with an accusation that the merchant had forged it. The flagship demo
did not work at all. A 404 is evidence only once a watcher is known to be
answering, so presence is probed on the payer route's own CORS terms, and
/healthz now carries that grant instead of being blocked exactly where it was
needed.

Three more, all the same shape - the fix landed on the case it was shown:

- A refusal wrapped in a generic envelope was still read as "may have been
  submitted". Round 8 stopped taking the first code for UNRECOGNISED codes and
  left it live for known-but-not-pre-submission ones, so UNKNOWN_ERROR around
  USER_REFUSED_OP locked the payer out while telling them they had dismissed
  the prompt. A pre-submission code anywhere in the error now wins. Codes sent
  by name are understood, and a cyclic or throwing error object can no longer
  escape the classifier - it used to throw from inside the catch that builds
  WalletActionError, losing the submitted flag entirely.
- The store key gained a terms digest with no migration read, so a payer
  mid-payment when the widget updates found no record of a broadcast that had
  already happened and paid again. The old key is read and carried forward, and
  the amount is normalised through the same parser the matcher uses: "2.50" and
  "2.5" were one invoice to matchesInvoice and two keys to the store.
- Both create-failure paths deleted by id with no identity check, while the
  write path 20 lines below carried the guard. A create that failed after its
  id had been released and reused deleted the live invoice holding it, freeing
  an address a payer's link still pointed at.

172 tests; the six new guards verified by breaking them, including one that
needed a visit counter because a catch-all was masking the failure.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
B
bongbongcrypto committed
22768abf4ccc10b094cf8b389304eda87f4640d7
Parent: 54d3011