fix: Cloudflare 在前时按 CF-Connecting-IP 取来源地址

[stqfdyr]

问题

#28：域名开了 Cloudflare 代理、再由本地 nginx / caddy 反代到 hub 时，X-Forwarded-For 的最后一跳是 Cloudflare 边缘的地址（截图里的 162.158.88.126）。hub 把它当成节点的连接来源：

• NAT 节点在面板上显示的「出口」是 Cloudflare 的地址
• 网卡上没有公网地址的节点，国家码按 Cloudflare 的地址查，公开页的旗帜跟着错

节点取址的规则是「网卡上的地址归 agent，出口归 hub」，Cloudflare 在前时出口这一半从来就不对。

改动

新增 auth::node_ip，agent 握手在验过节点 token 之后用它取来源：请求带 CF-Connecting-IP 时用它，否则与 client_ip 相同。Cloudflare 的代理与隧道都会把节点的真实地址写进这个头。

登录限流、注册锁定、登录通知仍用 client_ip，不读这个头。 能从 Cloudflare 网络连到源站的不只 Cloudflare 的代理：Worker 的原始 TCP socket 同样从 Cloudflare 的网段出来，请求头随便写。按「来源在 Cloudflare 网段内就采信」的做法（本 PR 第一个提交），任何人都能换着值绕过登录锁定，或填上管理员的地址把他锁在外面，而且对不在 Cloudflare 后面的 hub 同样生效。第二个提交改成现在的做法，网段表随之删除。

只在节点连接上读这个头不新增伪造面：持有节点 token 的一方本来就能上报任意地址（hello 里的 ipv4 / ipv6）。

顺带覆盖的：隧道先到本机 nginx 再到 hub 的链路，链尾是 127.0.0.1，但 CF-Connecting-IP 一路带着，节点地址同样取对。

开了代理时，登录限流仍按边缘地址计，同一个边缘后面的访客共用一个桶，这一点与现在相同。别家 CDN 由反代的 realip 配置把边缘换回访客地址，见配套文档 PR。

验证

cargo fmt --check、cargo clippy --all-targets -- -D warnings、cargo test（108 个）通过。forwarded_header_is_trusted_only_behind_a_local_proxy 补了断言：Cloudflare 在前时 client_ip 仍是边缘，node_ip 是节点；没有这个头时两者相同。

端到端：独立的 network namespace 里给 lo 加上一个 Cloudflare 边缘地址、一个「直连访客」地址和一个「别家 CDN」地址，前面放 nginx，用带有效节点 token 的 WebSocket 握手看 hub 记下的节点来源：

场景	修复前（v1.1.0）	修复后
Cloudflare 边缘 → nginx（文档里的配置），节点 203.0.113.7	162.158.88.126	203.0.113.7
Cloudflare 边缘直连 hub	162.158.88.126	203.0.113.7
cloudflared 在本机	203.0.113.6	203.0.113.6
别家 CDN → 配了 realip 的 nginx，节点 203.0.113.8	203.0.113.8	203.0.113.8
直连配了 realip 的 nginx，伪造 XFF	198.51.100.50	198.51.100.50
持 token 直连源站，自带 CF-Connecting-IP	198.51.100.50	自带的值（持 token 本来就能报任意地址）

登录限流：从同一个 Cloudflare 边缘连续 6 次输错密码，每次换一个伪造的 CF-Connecting-IP，结果 401 401 401 401 401 429，头没有被当成新的身份。

兼容

无 schema、接口、agent 协议变化。升级后节点重连时按新的来源更新出口，地址变了的会重新查一次国家码。

配套文档：monitor-probe/monitor-document#9。

Closes #28