auth: refused-URL docs incomplete and the loopback startup message is misleading #341

Non-blocking findings from the review panel on #340 (the #326 implementation).

1. Refused-list wording. README and CHANGELOG say an embedded app's metadata URL is refused if it is "relative, non-http(s), plain-http non-loopback or non-public-IP". Also refused: plain-http to a loopback host, loopback names such as localhost, and an unparseable port. "Plain-http non-loopback" reads as if http to loopback were allowed; it isn't (for a public auth URL). State the rule as what is accepted: an absolute https:// URL with a public DNS name or public IP and a valid port (loopback http:// only where the code allows it, if anywhere).
2. Loopback message. For http://127.0.0.1… (metadata, or the JWKS URL via the CLI) the startup error is "only allows http:// URLs for loopback hosts" — false for a loopback host. The text predates fix(auth): operator messages through a checked registry; refuse unrenderable auth config at startup; README /mcp rule (see Consiliency/pmcp#326) #340 (it is sanitize_public_auth_url's), but fix(auth): operator messages through a checked registry; refuse unrenderable auth config at startup; README /mcp rule (see Consiliency/pmcp#326) #340 makes it a startup error. Reword the registry member so it is true for every input that reaches it.
3. Nit. One README sentence groups the metadata URL with the CLI rule; the CLI never takes a metadata URL.
4. Nit (gemini). _is_absolute_http(parsed: Any) could be annotated with urllib.parse.SplitResult | ParseResult.

The registry rules from #326 apply: rewording goes through AuthMessage, and the sanitiser test must still pass.

See #340, #326.