feat(platform): assemble persistent local Agent lifecycle

[LichKing-2234]

Problem

既有 Platform 管理、配置、Store、Registry、Secret、模型预检及 Workload 调谐组件尚未组成可启动的真实 API/Worker。初次申请还依赖旧 delegated Action admission，Agent 网络策略固定拒绝所有出站，因而已有组件测试不能证明本地申请、审批和模型配置能够运行。

本票是 #150 下唯一的现有员工 Web 生命周期生产装配入口，供 #481 的新增 API 治理和 #482 的持久任务生产循环复用。开发按已确认的 Connection 独立直连边界推进，将 #432 的相应能力视为外部接口假设；后续联调按真实交付修正，外部契约等待不阻塞本票开发。

Scope

• 以 main 022485c4c14280080668ab754bd411845480cf8b 的已交付组件和 docs(platform): align M1 engineering and Runtime task contracts #477 候选 d201642ba87ce2dbdebf12d692fee681230ffbb3 的独立直连方向为开发基线。代码在独立分支交付，保持 feat(runtime): implement Generic ACP and OpenCode core conformance #438/docs(platform): align M1 PRD, engineering and Runtime contracts #475/docs(platform): align M1 engineering and Runtime task contracts #477/docs(runtime): align M1 API task and execution evidence contracts #480/docs(connection): align M1 to an independent MCP/API product #432 的原执行归属；正式合流重新核对实际契约和当前提交的全部门禁。
• 在 Platform 侧退役初次申请与 Owner 配置对 delegated Action admission/Catalog 的依赖。按独立直连目标处理旧 Action 配置、revision 和读写契约，提供必要的版本化迁移及生成 Client 回归，包括 Workload candidate/verified 内嵌配置快照；保留既有 revision/fence、Secret 引用和回滚一致性；不返回伪造的 Catalog/授权或任意成功 revision，不恢复 Gateway/assertion，不在 Platform 保存 Connection 凭据。
• 模型生命周期遵循 PRD 创建申请及 Owner 后续配置要求。保持当前真实初始模型准入、候选验证及失败不激活语义；是否增加审批后的首次配置由产品范围另行明确，本票不自行引入未配置运行状态。
• 装配既有 API 的可信 IdentityAdapter、身份复核、浏览器会话、Registry/模板/模型准入、ID 分配、Secret 加密与 projection。复用现有 Core/Store，保留 Web 创建审批；具体身份产品和真实账号配置作为部署输入，开发和测试可使用可控依赖，最终实装不能使用固定管理员身份。
• 装配正式 Worker 的 Workload reconciliation、限定 namespace 的 Kubernetes client、Registry、Worker-only 解密、模板/模型绑定、Runtime probe、PVC 和生命周期。API、Agent 及其他部署单元不获得 Kubernetes credential 或 Worker 解密私钥。 就绪检查采用经 Spec §9.3/HLD §4/ADR 0010 独立评审的 Workload Readiness Grant，绑定当前 Worker/Agent/revision/fence/Digest，最长 30 秒，只读核心和 capability，不伪造业务 ID 或 Action revision；该证明不能授权任务、会话、模型、工具或 Connection。
• 在唯一 Worker Kubernetes Adapter 中实现由部署配置的固定模型网络路径及必要 DNS，分别验证 Worker 预检和 Agent 出站。保持 Agent 到 Platform/Connection DB、Kubernetes API 和非获准目标的拒绝；网络配置不是 Owner 可写的产品能力。
• 提供可复用的本地 API/Worker 启动、状态和停止入口、脱敏配置示例及明确的数据重置说明，复用已有 Compose/kind/数据库/对象存储。真实配置缺失时给出具体、脱敏的错误，组件健康与业务验收分别报告。
• 共享入口、部署配置和 lockfile 由一个集成负责人串行处理。feat(platform): deliver user and application Agent management API #481 消费本票生命周期基础，保留其用户/应用凭证和 direct API 验收；feat(platform): deliver durable Agent task API and dispatch #482 独占首次生产 Conversation/task 工作发现、claim/调度、执行授权/Runtime Grant、任务路由和事件持久消费。不得新增旧 Web 专用投递循环。
• 本票不实现 Connection 服务、OAuth Authorization Server、Provider/GitHub Action、feat(runtime): persist actual model and tool execution facts #483 执行事实、feat(web): implement conversation timeline and execution controls #192 对话 UI、Eval、文件或企微。实际 Connection 契约差额记录在接入边界并随后修正；真实授权和真实 GitHub PR 仍属于整体本地闭环验收，不能以测试替身计为完成。

Acceptance criteria

• AC-1: 新空 Platform 业务库经可信身份完成现有申请 → 审批 → Worker 创建 Workload → Owner 后续模型配置与验证流程；该路径不再需要旧 delegated Action admission。旧非空 Action 配置的迁移/失效结果明确，不产生伪造 Catalog revision 或授权，其他生命周期/模型配置语义保持。
• AC-2: 正式 API 部署入口组合真实 Store、Registry、ModelCatalog、Secret 和身份边界；使用者/管理员由服务端解析，非法身份、普通员工审批、跨主体读取及身份依赖失败均拒绝。浏览器会话符合 HttpOnly/Secure/SameSite 和当前账号复核要求。
• AC-3: 正式 Worker 自动从 DB 调谐真实 Codex Workload，实际镜像 digest、Agent/revision、模型配置、Secret 引用及 PVC 一致；候选失败保留已验证配置。无需手工创建业务 Agent 或绕过审批写库。
• AC-4: Worker 模型预检使用所选模型及相应凭证，Agent 的获准模型路径实际可达，非获准目标及 DB/Kubernetes 访问被拒绝。保留同一实际网络配置的有效正向与负向证据，缺失 CNI、静态 YAML 或模型自报不能代替。
• AC-5: 停止/重启 Agent 和 API/Worker 后配置、审计、active revision 和 PVC 数据按既有语义保留；失败和缺配置均有脱敏诊断。原始凭证不进入源码、日志、Issue、镜像或普通 API 响应。
• AC-6: 从干净源码、固定镜像和空业务数据重复完成上述生命周期流程，给出启动/status/stop、单列重置命令，以及源码、镜像、配置和契约版本证据。
• AC-7: 确定完整 M1 的阶段、实施 Issue 边界与依赖 #150/feat(platform): deliver user and application Agent management API #481/feat(platform): deliver durable Agent task API and dispatch #482 的唯一交付边界明确并回读，原有新增 API/任务/四模板/联合验收义务保留。本票没有第二套 Conversation/task loop 或 Connection 权威。
• AC-8: 完成 AGENTS.md 要求的验证、当前提交 Standards/Spec Review 及适用人工/CODEOWNER 门禁；生成契约/迁移/旧客户端兼容有相应回归。明确区分开发假设、实装证据和待完成的真实 Connection/浏览器端到端验收，外部假设未核实时不宣称整个 Goal 达成。

Validation

• 复用现有 Core/Store、Secret、Registry、ModelCatalog 与 Workload conformance，仅为实际装配、旧 Action 退役及网络边界增加必要测试。契约变更执行单向生成、漂移和 breaking-change 检查；数据库变更使用增量 migration，覆盖旧配置和新空库。
• 使用真实 PostgreSQL 和独立 kind/CNI 验证申请/审批/配置/Workload/停止/重启，回读 DB、StatefulSet、Service、PVC、Secret 引用和 active revision。Kubernetes 命令必须显式指定本地 kubeconfig/context/namespace。
• 身份测试覆盖匿名、伪造、过期/重放（按所选信任机制适用）、角色、跨主体和依赖不可用；真实身份入口和模型输入只在实际接入步骤索取，测试替身不能作为最终真实身份验收。
• 对模型网络使用相同 Pod/Profile 的实际正负请求，并验证 Worker 与 Agent 两条路径；执行中保持数据库和 Kubernetes credential 隔离，不通过额外 allow-all NetworkPolicy 绕过唯一调谐。
• 从仓库根按 AGENTS.md 顺序执行 frozen install、check、check-types、test、build、smoke、docker:build、Markdown lint/link、workflow policy、actionlint 与 git diff --check。通过独立 Standards/Spec Review 后提交 PR，最终合流重新绑定源码/契约和当前 head 证据。

外部交接是联调和最终验收条件：#432 提供独立 Connection 的实际客户端授权/调用契约，#475/#477 提供最终合入版本；本票依据已明确的开发假设先行实现并在交接后对齐。既有 #192/#194/#481/#482/#483 的原生依赖保留，不以本票替代或降低其验收。

Blocked by

None