ip-verifier: deployment, key custody, and monitoring

[elitegreg]

Part of RFC-27 (tracker: #4194). Depends on #4198.

Ship the service built in #4198.

What

• Dockerfile and release packaging following the pattern in controlplane/* and release/.
• Deploy to devnet and testnet, behind TLS at a stable hostname per environment. The hostnames become the client defaults in the CLI issue, so pick them here.
• Load balancer and proxy configuration that preserves the real client source address, matched to the trusted-proxy CIDRs the service is configured with. Verify end to end from a known external IP that the signed client_ip equals that IP — a misconfiguration here silently signs the wrong address for every user.
• Verifier keypair custody: where it lives, who can read it, and the rotation procedure via SetAuthority (serviceability: add ip_verifier_authority_pk to GlobalState and rotate it via SetAuthority #4196). Note that rotation invalidates outstanding proofs and clients re-verify on their next connect.
• Alerts: service down, signing failures, epoch source stale, and an unusual rate of proof issuance for a single source IP.

Acceptance

• Service reachable in devnet and testnet, /health green, dashboards and alerts wired.
• Documented verification that the observed source IP matches the true client IP through the full ingress path.
• Rotation runbook written and dry-run once in devnet.