docs: qualify the loopback claim, in both directions

Copilot's sixth pass, and it is my own round-4 failure repeating: I wrote that
"loopback is not a boundary a browser enforces" and that ANY open page can
reach ws://127.0.0.1 -- an absolute where the evidence supports a qualified
claim. Same shape as asserting a WS handshake carries no credential.

CHECKED RATHER THAN TAKEN, and the finding is itself overstated. Copilot says
"current Chromium gates WebSocket access from a public origin to localhost
behind Local Network Access". Chrome's own documentation (developer.chrome.com
/blog/local-network-access) says the opposite for the case at hand:
WEBSOCKETS WERE NOT YET GATED when the permission prompt began shipping, with
coverage planned. So the mitigation exists and is rolling out; whether it
covers THIS socket, in a given browser at a given version, is exactly what
neither of us can state and what no test here can settle.

The text now says that, and keeps two gaps that are structural rather than
version-dependent: LNA is a Chromium feature, so other browsers need not
behave alike; and it engages only for a PUBLIC origin, so the locally-served
page this paragraph is about falls outside it entirely. The threat is kept,
the reassurance is not offered, and the durable fix is named -- the server
checking Origin, which it does not do.

Grepped the same claim through the rest of the section, per the rule this PR
earned: the two remaining "any hostile page" statements are about the REMOTE
wss:// endpoint, which LNA does not gate at all (it gates public->local), so
they are correct unqualified and were left alone. The distinction is the
whole point of the fix.

1193 passing, unchanged; no code touched.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

README.md

@@ -222,11 +222,24 @@ below is needed to develop, to demo locally, or to share a TUI-hosted document
 with another tab on the same machine.
 
 One caveat even there, for the reason spelled out below: a WebSocket is exempt
-from the same-origin policy, and loopback is not a boundary a browser enforces
-— so while the server is running, **any** page open in that browser can connect
-to `ws://127.0.0.1:8787` and read or edit the document. Nothing in the server
-checks `Origin`. That is tolerable for a local session you start and stop, and
-it is the reason not to leave one running unattended.
+from the same-origin policy, and **nothing in the server checks `Origin`** — so
+a page you did not open can connect to `ws://127.0.0.1:8787` and read or edit
+the document while the server runs.
+
+How much the *browser* mitigates that is in flux and should not be leaned on.
+Chromium has been rolling out **Local Network Access**, which puts requests
+from a public-network origin to a loopback or private-network address behind a
+permission prompt; per Chrome's own documentation WebSockets were **not yet**
+covered when the prompt began shipping, with coverage planned, so whether a
+given browser and version gates *this* socket is not something this project can
+state — and there is no browser here to test it in. Two gaps are structural
+rather than version-dependent: it is a Chromium feature, so other browsers need
+not behave the same; and it only engages for a **public** origin, so the
+locally-served page this section is about is outside it entirely.
+
+Treat it, then, as tolerable for a local session you start and stop, and as a
+reason not to leave one running unattended. The durable fix is the server
+checking `Origin` itself, which it does not yet do.
 
 ### Sharing a TUI-hosted document with a remote browser