fix(wallet): sepolia claimed a pool address that does not exist

POOL_ADDRESS held the mainnet address on both networks, copied across.
starknet_getClassHashAt answers "Contract not found" for it on sepolia, so the
fee lookup called nothing, landed in its catch and returned null, and a sepolia
payer was quoted no fee at all with nothing said about why. An exported constant
asserted an address that is not there, and everything downstream treated it as
fact.

sepolia is null now, and the lookup separates "no pool on this network", which
is knowable without asking, from "the node did not answer", which is what the
catch is for. Copying the mainnet address back in fails a test.

Also in this pass:

- scripts/check-claims.mjs. The test count in the README went stale three times
  in one day, corrected by hand each time. It now runs the suite, counts the
  manifest and asks the chain for the fee, then compares all of it against every
  number the docs state. It found both stale counts on its first run.
- A test that the two-line summary above the pay button cannot name a fact the
  full list does not, or put it on the wrong side, or miscount the rows. On a
  product whose argument is that it does not overstate its privacy, a summary
  drifting from what it summarises would be the worst defect available. Two
  mutations of it fail.
- .gitattributes. A clone on Windows showed twenty-three modified files the
  moment anyone ran the build, which reads like the repo is out of sync with its
  own source.

Verified this pass, unchanged: a fresh clone installs, tests and builds; the
committed dist is byte-identical to what the source produces once line endings
are normalised; the packed tarball installs into a clean project and every
documented export works, including the /react subpath and the type declarations;
the hub's own verifyTransactions counts 7 of our 7; npm run e2e:watcher passes
all nine checks against mainnet; the watcher refuses every route without its
token, survives prototype pollution, a 10MB body and malformed JSON, and allows
only its configured origin; no invoice id ever reaches the filesystem and the
webhook URL cannot come from a request.