Explain delivery_ips_not_public when a VPN/gateway hides the caller

[njb90]

Summary

Behind a corporate VPN or secure gateway (e.g. Cloudflare WARP), the provisioning API can see the request arriving from a private address. The requester's address is always folded into the delivery allow-list, so provisioning fails with delivery_ips_not_public — no flag avoids it, and the bare 400 gives the user (or an AI agent driving the CLI) nothing to act on.

This adds guidance when that error's rejected private address was server-derived rather than user-supplied:

• Human mode: dim stderr text after the error line, matching the existing rate-limit/registration-disabled hint pattern.
• --json: additive hint field inside the existing error envelope (non-breaking).
• Wording is deliberate for AI agents: names the routing cause, states explicitly it is not a security block, and instructs agents to report to the user and never change network/VPN settings themselves.
• Suppressed when the hint would be wrong or redundant: the user passed the rejected IP via --ip (compared with IPv6 normalization, not string equality), every rejected address is public, or the message has no parseable IP while --ip values were given.
• README gains a troubleshooting bullet for the same situation.

Lives in ip-check.ts alongside the existing delivery-IP/VPN logic and reuses its isPublicIp; not added to the public library surface.

Test plan

• 7 unit tests: derived-private hint content, user-supplied suppression, IPv6 normalized comparison, multi-IP messages, all-public suppression, unparseable-message attribution, prose false-positives (times/hex)
• 2 integration tests spawning the real CLI against a stub API: hint present in --json error envelope; human mode emits guidance on stderr
• Full suite 63/63

🤖 Generated with Claude Code