docs(sirius-press): record what the browser found, and what still has not been run

The docs said nobody had clicked the buttons in a browser. Somebody has now,
and it cost two bugs, so testing.md gains a section saying to do it after
touching the auth assets — the HTTP suites cannot see that class of failure.

Also sharpens the honest gap: the Docker stack has not been run anywhere, not
just 'not on a clean Ubuntu box'.

CHANGELOG.md

@@ -85,10 +85,33 @@ static copies of its pages to a BCNR name.
   already pass and the filter never fired. The documentation said otherwise
   and has been corrected.
 
+### Fixed after opening it in a browser
+
+- Wallet sign-in did not work in a browser at all. WordPress marks its
+  username and password inputs `required`; the wallet path leaves both empty
+  on purpose, so the form refused to submit a valid signature and pointed a
+  validation bubble at a field the visitor is not meant to fill in.
+- The `hidden` attribute was being overridden by WordPress's own button
+  styles, so controls this plugin ships hidden were visible regardless —
+  offering a browser wallet that is not there, and showing a JavaScript-only
+  button to visitors without JavaScript.
+
+### WordPress 7.1.2
+
+Taken through `tools/update-wordpress.sh` and merged cleanly; upstream did not
+touch the one file this fork patches. Two bugs in the update tool surfaced
+doing it: a Windows path-subtraction that produced an absolute `--prefix`, and
+git-subtree's refusal to run in a repository with any uncommitted file. The
+merge now runs in a scratch worktree and a failed run can be retried.
+
 ### Known gaps
 
 - `install.sh` and the Docker stack are written and syntax-checked but have
-  not been run on a clean Ubuntu box.
+  never been run — not on a clean Ubuntu box, and not locally either, since
+  Docker would not start on the machine this was built on. Largest untested
+  surface in the project.
+- Manual-mode publishing (browser signs and uploads) has not been clicked
+  through; the server-signing path has.
 - Publishing is verified against a transcription of the gateway's own
   verification logic, not against `navigate.st` with a registered name.
 - Seven of the ten rows in the plugin compatibility matrix are reasoned rather

README.md

@@ -184,12 +184,14 @@ On WordPress 7.1.1, against a live instance:
   activate, and leave every Sirius Press screen rendering cleanly.
 - Publishing: 29 files signed by the server and accepted by a gateway running
   the real verification logic, read back intact, with a wrong key refused 403.
-- An upstream version bump through `tools/update-wordpress.sh`, reapplying the
-  patch series.
+- Signing in **in an actual browser**, which found two bugs the HTTP suites
+  structurally could not — see docs/testing.md.
+- Taking WordPress **7.1.2** through `tools/update-wordpress.sh`: imported,
+  three-way merged into the subtree, clean, tests still green.
 
-Not yet run: `install.sh` on a clean Ubuntu box, and an upload to the real
-gateway with a registered name. [docs/testing.md](docs/testing.md) says how to
-do both and what each proves.
+Not yet run: `install.sh` on a clean Ubuntu box — or the Docker stack at all,
+anywhere — and an upload to the real gateway with a registered name.
+[docs/testing.md](docs/testing.md) says how to do both and what each proves.
 
 ---
 

docs/testing.md

@@ -142,11 +142,45 @@ verifies with the same library the gateway does, not with ours.
 
 ---
 
+## In a browser
+
+Everything above drives the site over HTTP, which is fast and repeatable and
+misses a whole class of bug. Two got through it and were only found by opening
+`wp-login.php` in a browser and clicking the button:
+
+- WordPress marks its username and password inputs `required`. The wallet path
+  leaves both empty on purpose, so `requestSubmit()` failed constraint
+  validation and refused to send a perfectly good signature — with a bubble
+  pointing at a field the visitor is not meant to fill in.
+- The `hidden` attribute does not survive WordPress's own stylesheet.
+  `.wp-core-ui .button { display: inline-block }` outranks the UA rule that
+  makes `hidden` work, so buttons this plugin ships hidden were on screen
+  anyway, inverting the progressive-enhancement design.
+
+So: **after changing anything in `plugins/sirius-press-auth/assets/`, open the
+login page and click the button.** The HTTP suites will not tell you.
+
+Serve the throwaway instance and point a browser at
+`http://127.0.0.1:8760/wp-login.php`. `127.0.0.1` counts as a secure context,
+so WebCrypto works over plain HTTP there — on any other host the in-page
+wallet needs real HTTPS, and the script says so and falls back to the paste
+box.
+
+Worth checking by hand, in this order: the sign-in button appears, the
+browser-wallet button does *not* (unless you are in Theseus), typing the
+phrase and clicking signs and lands you on the dashboard, and the challenge
+text in the box matches what your wallet shows you.
+
+---
+
 ## What is not covered
 
 - **A fresh VPS install.** `install.sh` and the Docker stack are written and
-  syntax-checked but have not been run against a clean Ubuntu box.
+  syntax-checked but have never been run — not on a clean Ubuntu box and not
+  locally, since Docker would not start on the machine this was built on.
+  This is the largest untested surface in the project.
 - **A real gateway upload.** Verified against the transcribed verifier above,
   not against `navigate.st` with a registered name.
-- **Browser UI.** The signing scripts are exercised through Node, which runs
-  the same code, but nobody has clicked the buttons in a browser.
+- **Manual-mode publishing in a browser.** The server-signing path is
+  exercised end to end; the browser-signs-and-uploads path in
+  `assets/export.js` has not been clicked through.