feat(runtime-host): add managed update reconciliation policy

[M4n5ter]

English

Problem

Managed Runtime Host update discovery and the verified exact-package update transaction are available, but there is no installation-owned policy or bounded operation that converges a service toward its configured target. Future schedulers and Desktop controls would otherwise need to duplicate selector resolution, admission, and retry behavior.

Desired outcome

• Persist one mutually exclusive manual | fixed | latest | next policy, defaulting to manual.
• Resolve mutable channels to one exact version and verified package integrity before mutation.
• Provide one bounded, machine-readable reconciliation command that delegates to the existing update transaction.
• Keep unattended reconciliation fail-closed for active work and targets requiring manual action.
• Preserve a stable terminal contract for current, changed, blocked, manual-action, and retryable outcomes.

Schedulers and Desktop UI are intentionally out of scope. They should later invoke this same one-shot contract instead of implementing update behavior themselves.

Alternatives or workarounds

Operators can currently run check-update and update manually. Keeping policy only in each future caller would create multiple update state machines and inconsistent recovery behavior.

Depends on #3687. Tracks the next reconciliation slice of #3228 and establishes the architecture gate needed by #3709.

简体中文

问题

Managed Runtime Host 已具备更新发现和经过验证的精确 package 更新事务，但还没有由 installation owner 持有的策略，也没有将 service 收敛到配置目标的有界操作。若直接继续实现 scheduler 与 Desktop 控制，它们会分别复制 selector 解析、准入和重试行为。

期望结果

• 持久化互斥的 manual | fixed | latest | next 策略，默认 manual；
• 在任何 mutation 前，将可变频道解析为精确版本和已验证的 package integrity；
• 提供一个有界、机器可读，并委托给现有 update transaction 的 reconciliation 命令；
• active work 或目标需要人工处理时，无人值守 reconciliation 必须 fail closed；
• 为 current、changed、blocked、manual action 与 retryable outcome 保持稳定的 terminal contract。

Scheduler 和 Desktop UI 不属于本 issue。它们后续应调用同一个 one-shot contract，而不是各自实现更新逻辑。

替代方案或当前做法

Operator 目前可以手动执行 check-update 和 update。若让每个未来调用方各自保存策略并编排更新，会产生多套状态机和不一致的恢复语义。

依赖 #3687；属于 #3228 的下一项 reconciliation 切片，并建立 #3709 所需的架构门槛。