fix(cluster): 以宁波专用节点替换深圳 Worker

移除深圳节点及中继拓扑，新增第二台宁波 K3s agent 的全互联 WireGuard 接入和严格 UFW 门禁。\n\nWorker Deployment 与容量控制器仅选择 easyai.io/worker=true 节点，使原宁波混部节点退出 Worker 资源预算，生产基线恢复为宁波专用节点与香港节点各一实例。\n\n已通过 Go 全量测试、go vet、gofmt、迁移安全检查、bash -n、ShellCheck、发布脚本测试和 Kubernetes 清单渲染。

docs/operations/k3s-ha-runbook.md

@@ -6,22 +6,23 @@
 CloudNativePG；洛杉矶只作为 K3s server/etcd 仲裁节点，并带
 `easyai.io/witness=true:NoSchedule` 污点。
 
-深圳扩展节点是纯 K3s agent，不加入 etcd 或 CloudNativePG。它使用节点名
-`easyai-shenzhen`、WireGuard 地址 `10.77.0.4`，并归入逻辑 `hongkong` Worker 池。
+第二台宁波服务器是纯 K3s agent，不加入 etcd 或 CloudNativePG。它使用节点名
+`easyai-ningbo-worker-2`、WireGuard 地址 `10.77.0.4`，并归入逻辑 `ningbo` Worker 池。
 `easyai.io/worker-only=true:NoSchedule` 污点确保除 Worker 外的业务 Pod 不会调度到该机；
-香港池副本通过 hostname topology spread 分散到香港、深圳。接入使用：
+`easyai.io/worker=true` 标签确保容量控制器只把专用 Worker 节点纳入资源预算。接入使用：
 
 ```bash
-./scripts/cluster/add-shenzhen-worker-node.sh all
+./scripts/cluster/add-ningbo-worker-node.sh all
 ```
 
-香港—深圳公网直连实测无法满足生产链路门禁，因此两地 `10.77.0.2/10.77.0.4` 数据前缀
-固定经宁波 WireGuard 中继；香港—深圳直接 peer 只保留加密心跳。巡检仍以两端实际数据路径
-的 10 包丢包率低于 1%、平均 RTT 低于 80 ms 为硬门禁，禁止自动回退到劣化的公网直连。
+新节点与宁波、香港、洛杉矶使用 WireGuard 全互联直连，不经过中继。公网 K3s 直连虽然可以
+单独保护 API TLS，但当前 Flannel、Pod 和数据库网络依赖 `10.77.0.0/24`，禁止改成未加密的
+公网 VXLAN。巡检以 10 包丢包率低于 1%为硬门禁；宁波和香港路径 RTT 低于 80 ms，洛杉矶
+路径低于 300 ms。
 
-本地 `.env.local` 只保存 `AI_GATEWAY_SHENZHEN_HOST` 和 SSH 接入密码，必须保持 `0600` 且
-不得进入 Git。深圳已有宿主机服务时，接入脚本保留其公开端口，只封锁 K3s API、kubelet、
-VXLAN 和除既有 `31058` 外的 NodePort 公网入口。深圳防火墙继续由原有 UFW 管理，接入脚本
+本地 `.env.local` 只保存 `AI_GATEWAY_NINGBO_WORKER_HOST` 和 SSH 接入密码，必须保持 `0600`
+且不得进入 Git。新节点只保留原有 SSH 入口，封锁 K3s API、kubelet、VXLAN 和全部 NodePort
+公网入口。节点防火墙继续由原有 UFW 管理，接入脚本
 禁止安装与 UFW 冲突的 `iptables-persistent`；UFW 未安装或未启用时必须在预检阶段停止。
 
 生产上线前的双节点高媒体负载、Worker 强杀和 P24/P28/P32 容量搜索见

docs/operations/production-acceptance.md

@@ -89,21 +89,22 @@ AI_GATEWAY_WORKER_REPLICAS_HONGKONG
 各一个 2 GiB Worker，再按实时内存、CPU 和 PostgreSQL 预算验证 `1+2`、条件允许时的
 `2+2`，以及安全 drain 回到 `1+1`：
 
-宁波因正式混部不具备 Worker 余量时，验收可改用 `0+2` 基线：
+生产基线使用两个独立物理 Worker 节点：第二台宁波服务器承载 `easyai-worker-ningbo`，
+香港服务器承载 `easyai-worker-hongkong`。两个 Deployment 都要求节点带
+`easyai.io/worker=true`，原宁波混部节点不再承载 Worker。默认验收配置为：
 
 ```bash
-AI_GATEWAY_ACCEPTANCE_BASE_REPLICAS_NINGBO=0
-AI_GATEWAY_ACCEPTANCE_BASE_REPLICAS_HONGKONG=2
-AI_GATEWAY_ACCEPTANCE_AUTOSCALING_MIN_REPLICAS_NINGBO=0
+AI_GATEWAY_ACCEPTANCE_BASE_REPLICAS_NINGBO=1
+AI_GATEWAY_ACCEPTANCE_BASE_REPLICAS_HONGKONG=1
+AI_GATEWAY_ACCEPTANCE_AUTOSCALING_MIN_REPLICAS_NINGBO=1
 AI_GATEWAY_ACCEPTANCE_AUTOSCALING_MIN_REPLICAS_HONGKONG=1
-AI_GATEWAY_ACCEPTANCE_AUTOSCALING_MAX_REPLICAS_NINGBO=0
+AI_GATEWAY_ACCEPTANCE_AUTOSCALING_MAX_REPLICAS_NINGBO=2
 AI_GATEWAY_ACCEPTANCE_AUTOSCALING_MAX_REPLICAS_HONGKONG=2
 ```
 
-此时香港逻辑池的两个 Worker 必须通过 hostname topology spread 分布在香港和深圳物理节点；
-固定容量仍是两个实例，自动伸缩阶段验证 `0+1 → 0+2 → 0+1`，最终 certified profile
-恢复 `0+2` 最小副本以保留双物理节点容灾。资源前置门禁采样实际启用的 Worker 站点节点，
-宁波仍受运行时 80% 目标和 85% 硬门禁约束。
+资源前置门禁和容量控制器只采样 `easyai.io/worker=true` 节点，避免把原宁波混部节点的
+可分配资源错误计入弹性上限。每站点能否升到两个副本仍由实测 RSS、CPU 和 PostgreSQL
+连接预算决定，不因新增节点而预先承诺。
 
 | 档位 | 单实例执行槽 | 数据库池 | 媒体并发 | 全局执行槽 |
 |---|---:|---:|---:|---:|