chore(release): 明确生产发布授权并支持集群发布

将发布与上线授权边界调整为一次明确的生产发布指令可连续执行 publish 和 deploy，同时保留仅构建镜像时的停止边界。

为现有发布脚本增加 compose/kubernetes helper 选择和显式 SSH 私钥支持，保持完整 SHA、digest 与生产基线校验不变。

验证：bash -n、ShellCheck、manual-release-test。

AGENTS.md

@@ -52,14 +52,14 @@ docker compose -f docker-compose.yml config --quiet
 2. `main` 不设置受保护分支或 required status；Agent 在获得用户明确授权后，可以合并已验证的 PR，也可以直接提交并推送 `main`。操作前必须获取最新 `origin/main`、确认工作区边界、检查提交差异和敏感信息，并执行与风险匹配的本地验证。
 3. 不得等待、伪造或手工补写已经取消的 CI status，也不得为了满足旧流程擅自恢复 Gitea Actions。Git 提交、合并、Push 和 Tag 授权只覆盖源码历史变更，永远不等于 publish 或 deploy 授权。
 4. 发布只能使用工作区干净、已经提交并属于 `origin/main` 历史的完整 SHA。镜像 Tag 使用完整 SHA，线上只能使用 Registry digest，禁止使用 `latest`。
-5. 本地镜像发布必须由用户明确要求后单独执行：
+5. 本地镜像发布必须由用户明确要求后执行：
 
    ```bash
    ./scripts/publish-release-images.sh --components auto
    ```
 
-   该命令只能构建、冒烟、推送镜像和生成 `dist/releases/<SHA>.json`，不得修改生产。
-6. publish 成功后，Agent 必须报告 manifest、组件、digest 和验证结果并停止。只有用户再次明确确认上线，才可单独执行：
+   该命令只能构建、冒烟、推送镜像和生成 `dist/releases/<SHA>.json`，不得修改生产。用户只要求“构建镜像”“推送镜像”或明确限定为 publish 时，执行到此为止。
+6. 用户明确要求“发布”“上线”或“部署到线上”时，该次授权同时覆盖 publish 和 deploy。publish 成功并核验 manifest、组件、digest 和验证结果后，应直接继续执行下列部署命令，无需再次请求确认：
 
    ```bash
    ./scripts/deploy-production-release.sh dist/releases/<SHA>.json