feat(cluster): 接入深圳专用 Worker 节点

新增深圳 K3s agent 与四节点 WireGuard 全互联接入脚本，将深圳归入香港逻辑 Worker 池并用污点限制为 Worker 专用。\n\n生产验收支持宁波 0、香港逻辑池 2 的双物理节点基线，补充副本拓扑分散、容量档位、链路巡检和零副本站点校验。\n\n已通过 Go 全量测试、go vet、govulncheck、迁移安全检查、ShellCheck、发布脚本测试、前后端 lint/test/build、Compose 与 Kubernetes 渲染校验。

docs/operations/k3s-ha-runbook.md

@@ -6,6 +6,19 @@
 CloudNativePG；洛杉矶只作为 K3s server/etcd 仲裁节点，并带
 `easyai.io/witness=true:NoSchedule` 污点。
 
+深圳扩展节点是纯 K3s agent，不加入 etcd 或 CloudNativePG。它使用节点名
+`easyai-shenzhen`、WireGuard 地址 `10.77.0.4`，并归入逻辑 `hongkong` Worker 池。
+`easyai.io/worker-only=true:NoSchedule` 污点确保除 Worker 外的业务 Pod 不会调度到该机；
+香港池副本通过 hostname topology spread 分散到香港、深圳。接入使用：
+
+```bash
+./scripts/cluster/add-shenzhen-worker-node.sh all
+```
+
+本地 `.env.local` 只保存 `AI_GATEWAY_SHENZHEN_HOST` 和 SSH 接入密码，必须保持 `0600` 且
+不得进入 Git。深圳已有宿主机服务时，接入脚本保留其公开端口，只封锁 K3s API、kubelet、
+VXLAN 和除既有 `31058` 外的 NodePort 公网入口。
+
 生产上线前的双节点高媒体负载、Worker 强杀和 P24/P28/P32 容量搜索见
 [生产同构验收模式与高媒体压力测试](production-acceptance.md)。
 

docs/operations/production-acceptance.md

@@ -89,6 +89,22 @@ AI_GATEWAY_WORKER_REPLICAS_HONGKONG
 各一个 2 GiB Worker，再按实时内存、CPU 和 PostgreSQL 预算验证 `1+2`、条件允许时的
 `2+2`，以及安全 drain 回到 `1+1`：
 
+宁波因正式混部不具备 Worker 余量时，验收可改用 `0+2` 基线：
+
+```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_AUTOSCALING_MIN_REPLICAS_HONGKONG=1
+AI_GATEWAY_ACCEPTANCE_AUTOSCALING_MAX_REPLICAS_NINGBO=0
+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% 硬门禁约束。
+
 | 档位 | 单实例执行槽 | 数据库池 | 媒体并发 | 全局执行槽 |
 |---|---:|---:|---:|---:|
 | P24 | 24 | 32 | 24 | 48 |