fix(deploy): bound main cutover sessions

[yzxoi]

需求与摘要

修复 main deploy run 29499059767 attempt 2 在全部 OSS/CDN preflight 通过后，于 wallet-key 360 秒 drain 的静默窗口失去 SSH 进展、最终撞上 25 分钟 job timeout 的问题。N/A issue。

本 PR 同时收口链路存活、远端孤儿进程、并发发布、超时预算和不确定 cleanup 五个边界：

• SSH protocol keepalive 30 秒，3 次无响应即失败；drain 每 30 秒输出进度；
• drain 总时长仍严格为 360 秒，不缩短 300 秒 intent TTL + 60 秒 buffer；
• deploy job 上限调整为 60 分钟，远端命令有 45 分钟 TERM deadline + 30 秒 KILL grace，public probe 也有 connect/transfer timeout；
• 共享 proxy 更新、远端 preflight/cutover 与 cleanup 使用同一 mode-0600 non-blocking flock，阻止 runner 失联后的并发容器修改；
• cleanup 在删除 staged frontend release 前检查 main-fe 实际 bind mount，状态不确定或已生效时 fail-safe 保留。

产品行为与不变量

• 不改变钱包 migration 0067 的审批、drain proof、ledger verify 或 marker 写入条件。
• 新 backend 启动前收到 TERM/INT/HUP 会恢复兼容的旧 backend；一旦尝试启动新 backend，继续保持 forward-only，绝不回滚旧 schema reader。
• 不关闭 host-key 检查，不放宽 media/provider preflight，不记录 credential、public key 或签名 payload。

影响矩阵

• 产品行为或 Web UI
• contract/openapi.yaml 与 Web 生成类型
• PostgreSQL migration、backfill 或兼容窗口
• 身份、授权、PII、隐私、保留或审计
• 积分合规、签名、防重放或 ledger 完整性
• Media/OSS、search、cache、counter、notification 或 background job
• 依赖、配置、CI、部署或外部 provider

仅影响 main-staging GitHub Actions、版本化 deploy script、对应测试和运维 runbook。没有依赖、API、schema、业务逻辑或 provider credential 变化；wallet 安全窗口仅增加链路可观测性，时长与 fail-closed 条件不变。

文档影响

更新 docs/operations/deployment-and-previews.md：记录 SSH keepalive、heartbeat、双层 deadline、远端锁、信号恢复和 mount-aware cleanup。

验证

• python3 scripts/check_docs.py — passed
• Backend focused 与 CI-parity checks（如适用）— python3 -m unittest discover -s ops/deploy/tests -v: 37 passed；backend Rust 未变化
• Web generate/lint/typecheck/build（如适用）— N/A，Web 与 contract 未变化
• Fresh migration 与数据/并发检查（如适用）— N/A，无 migration；新增 deploy lock 与 TERM-during-drain 行为测试
• Desktop/mobile/accessibility 人工验收（如适用）— N/A

其他实际检查：

• shellcheck ops/deploy/deploy-main.sh — passed
• bash -n ops/deploy/deploy-main.sh — passed
• deploy runner block ShellCheck — passed（排除既有 SC2029 informational）
• workflow YAML parse — passed
• git diff --check — passed

Migration、部署与回滚

本 PR 不新增或修改 migration。合并会生成新的 main SHA 并触发包含修复的新 deploy；不要 rerun 旧 run，因为 rerun 仍使用旧 workflow。

合并/新 run 前需只读确认服务器没有旧 deploy-main/verify-oss 进程，核对 main-be revision/Cmd、rollback containers、0067 marker 权限与内容，以及 migrations 67–69/active-key invariant。若 marker 有效，移除旧 efba288 approval；若 marker 缺失，则把 approval 更新为本 PR 合并后的精确 main SHA，让新脚本重新完成 drain/verify 并原子写 marker，禁止手写 marker。

Preview 与证据

公网 /、/api/v2/health、/api/v2/ready 在失败后均返回 200；新 selection route 也存在，说明远端很可能继续启动了新版 backend，但公网探针不能证明 marker、精确 revision 或 migration ledger，因此不把它当作 cutover 完成证据。

本改动只触及 main deploy workflow/script，不触发 PR runtime preview；验证证据由上述部署测试与 workflow 静态边界测试提供。

已知限制与 Review 重点

• 首次使用新锁前，旧 run 使用的是无锁脚本，因此仍需一次 operator 只读状态检查。
• Reviewer 请重点检查 SSH 结果不确定时的 lock/mount cleanup 竞态、45m/60m deadline 层级，以及 TERM 前后 rollback 与 forward-only 边界。