feat(qr): add static and dynamic payment QR codes

IDEA-11 asks for both and the repo had neither.

Dynamic: one code per invoice, price in the link, shown beside the generated
link and behind a button on every dashboard row. Static: a counter code printed
once, where the payer names the amount at the till.

The encoder is written here rather than installed. Every QR package on npm runs
install scripts, and this machine holds the keys; byte mode at level M over
versions 1-20 is 666 bytes, which is far more than a payment URL needs, so the
rest of ISO/IEC 18004 is left out.

A QR that does not scan fails silently until a customer is standing there, so
the encoder is checked three ways that share no code with it: a decoder written
separately from the spec that rebuilds the function-module map itself and
verifies every Reed-Solomon syndrome; two fixed points published in the
standard (the Annex I error-correction example and the 32-entry
format-information table); and a pixel round-trip in qr-scan.html that goes
matrix, SVG, browser rasteriser, back, at three scales. Chromium on Windows has
no BarcodeDetector, so no third-party reader has seen these codes yet, and the
page says so rather than reporting a pass it did not get.

Two things fixed along the way:

- A pay-live link carrying no amount charged 2 STRK in silence. It now renders
  the counter view and asks.
- dev-static.mjs takes --port, so two sessions do not share one server.

A counter code publishes the merchant's takings: one address forever, so anyone
can total it and count the payments. Payers are unaffected either way, since
the pool severs who sent each one. The creator states that in the sentence
where the choice is made, not in a footnote.

196 tests pass, up from 180.