docs: stop giving ngrok a recipe I have not run

Copilot's third pass, on the flag I introduced LAST round while fixing the
flag I introduced the round before. Two consecutive rounds of writing an
access control into the README without running it is exactly the doctrine
committed in 5c1fefb, so this does not make it three by swapping in a
traffic-policy file I have also not run.

CHECKED AGAINST NGROK'S OWN DOCS RATHER THAN TAKEN:
 * ngrok.com/docs/agent/cli -- `--cidr-allow` is still ACCEPTED, marked
   deprecated with "use traffic policy instead". So Copilot's stated mechanism,
   "no longer accepts --cidr-allow, fails at startup", is OVERSTATED: it is
   deprecated, not removed. The substance (do not document it) stands; the
   reason is obsolescence, not breakage.
 * ngrok.com/docs/traffic-policy/actions/restrict-ips -- the action really is
   `restrict-ips`, supplied via `--traffic-policy-file`.

Knowing both spellings is still not knowing that a policy file I compose here
would deny anything, so the section now names the MECHANISM and points at the
documentation instead of offering a command line. A recipe that is right today
and silently wrong at the next major version is worse than a pointer, and the
spelling here has already changed once.

The same test applied to every other command line in the section, which is the
half worth more than the ngrok fix:
 * `improvise-ws-server bank-info.improv --port 8787` -- checked against clap
   in ws-server/main.rs: `files: Vec<PathBuf>` positional, `--port` long. OK.
 * the Caddyfile `@denied not remote_ip ...` / `abort @denied` -- checked
   against caddyserver.com/docs/caddyfile/matchers, which uses that exact
   idiom. OK, and still marked as not executed here.
 * `./web/build.sh`, `python3 -m http.server --directory web`,
   `cargo run -p improvise-ws-server -- examples/demo.improv` -- paths and
   targets exist. OK.

Also merged main, which brings the beads export in 4abcdaa. improvise-kpnr was
genuinely dangling in this diff before that and now resolves; the AGENTS.md
audit over README, repo-map, the ADRs and index.html reports 73 cited IDs
against 271 in the export with ONE miss -- improvise-m18f in repo-map gotcha
48, which is orchestrator-owned and already reported.

1193 passing (1184 + PR #20's), clippy and fmt clean.

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

README.md

@@ -319,12 +319,20 @@ For a one-off share with no DNS name and no certificate of your own,
 `cloudflared tunnel --url http://127.0.0.1:8787` or `ngrok http 8787` each
 print an https hostname that works the same way — pass the hostname to `?ws=`
 without a scheme. Both print a **public** URL and neither authenticates
-anything by default — and note that `ngrok http --basic-auth` does **not** fix
-that here, for the reason above: the page cannot answer a basic-auth challenge
-on a socket handshake. `ngrok http --cidr-allow` is the form that works, being
-the same address check as the Caddy example. An unguessable URL is not a
-control either. If you cannot put an address check in front of it, do not
-expose it.
+anything by default, and an unguessable URL is not a control.
+
+Two things carry over from above. `ngrok http --basic-auth` does **not** help
+here — the page cannot answer a basic-auth challenge on a socket handshake —
+and what you want instead is the same **address check** the Caddy example
+uses. But no command line for it is given here on purpose: ngrok has moved IP
+restriction from the (now deprecated) `--cidr-allow` flag to a Traffic Policy
+`restrict-ips` action passed with `--traffic-policy-file`, and cloudflared's
+equivalent is a product feature of its own. Those spellings have already
+changed once, none of them has been run in this repository, and a recipe that
+is correct today and silently wrong at the next major version is worse than a
+pointer — so: **consult their current documentation, and confirm the
+restriction denies before you trust it with a document.** If you cannot put an
+address check in front of the tunnel, do not expose it.
 
 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