deploy(ai-discovery): add safe existing-service update path

deployment/HLCC-PUSH-TO-DEPLOY-EVENT-PROTOCOL.hdlp

@@ -1,6 +1,6 @@
 # HLCC-PUSH-TO-DEPLOY-EVENT-PROTOCOL
 
-状态：本地实现候选，尚未部署
+状态：本地实现候选，尚未部署；当前现实层不得宣称可派发
 
 语言层在冰朔明确确认“该提交需要部署”后，主动发出 `guanghu.deployment-intent/v1`。推送本身不会产生部署事件。意图必须绑定：
 
@@ -11,3 +11,9 @@
 语言人格体通过 `/api/deployment/dispatch` 派发这一意图；接口要求一张单独的 `server-ops / dispatch-approved-deployment` 工单，且资源必须为同一 `REQUEST-ID@完整提交SHA`。服务端才写入 `guanghu.deployment-event/v1` 到本机队列。常驻部署 Agent 订阅此队列，读取同一提交中的清单，执行备份、部署、健康检查与回滚，并将回执回写到原工单。
 
 没有部署意图的提交照常入库，回执为 `not_requested`；无效意图回执为 `rejected`，不会部署。推送工单绝不扩大为部署权限；服务器也不扫描仓库主动拉取部署。
+
+`resource` 中的 `REQUEST-ID` 必须与清单文件名完全一致：`deployment/requests/<REQUEST-ID>.json`。批准 A 而执行 B 必须在派发端和常驻 Agent 端分别拒绝。
+
+首次新单元使用 `guanghu.architecture-provision-request/v1`；已经在线的 systemd 服务必须使用 `guanghu.existing-service-update-request/v1`，先完整备份声明目标，再重启和逐项验收，失败恢复全部旧文件与旧单元。二者不得互相冒充。
+
+当前京东节点若尚未安装 `/api/deployment/dispatch`、事件队列和常驻 worker，则先通过已有的主人邮件批准固定管理动作引导这套运行时。没有这个固定引导动作时应回执 `BOOTSTRAP_ACTION_NOT_DEPLOYED`，不得绕回人类 SSH 或云控制台，也不得发送一张服务器根本不会执行的部署工单。