docs: an allow-list is access control, not authentication

Copilot's seventh pass, reporting no new open findings; this is the one
carried item that is a real defect and it is cheap.

The closing note called the IP and Origin allow-lists "the auth above", in a
section whose opening sentence is that the server has NO AUTHENTICATION OF ANY
KIND. That muddies the exact distinction the section is built on: an
allow-list answers WHICH CLIENTS AND WHICH ORIGINS MAY CONNECT, never WHO is
connecting. Calling it auth invites a reader to think the hole is closed when
what has been added is a perimeter.

Checked every other use of the word in the section rather than editing the one
line flagged, per the grep rule this PR earned: "no authentication of any
kind" (the server), "HTTP basic auth" (genuinely authentication, and being
ruled out), "neither authenticates anything by default" (the tunnels) and
`--basic-auth` (a product flag) are all correct as written. One site, one fix.

The distinction is also exactly what improvise-kpnr has to decide, so the note
now says so.

1193 passing, unchanged; no code touched.

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

README.md

@@ -391,7 +391,10 @@ Note the server binds `127.0.0.1` by default and `--bind` is the only way to
 widen that. Behind a proxy on the same host you should *not* widen it: the
 proxy reaches loopback, and leaving the default keeps the **unencrypted** port
 off the network. That is worth doing and is not access control — the proxy is
-still the open door, which is why the auth above belongs there.
+still the open door, which is why the **access controls** above belong there.
+Those are access controls and not authentication, which the server still has
+none of: they answer *which clients and which origins may connect*, never
+*who* is connecting. The distinction is the whole of improvise-kpnr.
 
 ### Why not native `wss://`