fix(cli): diagnose residency-blocked local Runtime Host version conflicts

[me2seeks]

Problem

A local Maka upgrade can be blocked even when no Desktop or TUI is alive. The current TUI presents Wait and try again, or cancel? [W/c] for every RUNTIME_HOST_RESTART_REQUIRED conflict, but W only retries the same incompatible handshake every two seconds. It produces no progress or explanation.

This is especially misleading for an ephemeral Host recovered with a paused Goal:

• Goal authority intentionally retains Host residency for every non-terminal Goal, including paused.
• The old Host therefore remains the sole State Root writer after its original Client has exited.
• A newer Client cannot send a Domain command across a compatibility-epoch mismatch, so it cannot inspect or clear the paused Goal.
• Waiting alone cannot make a paused Goal terminal.

Reproduction

Observed on Linux with an isolated local State Root and then repeated against the active local workspace:

1. Start an ephemeral Runtime Host with compatibility epoch N.
2. Create and pause a Goal, then close the Client.
3. Start a TUI built with compatibility epoch N+1 against the same State Root.
4. The Host returns incompatible with replacement: blocked_by_residency.
5. Enter W; after at least three retry intervals, the TUI emits no further output and cannot progress.

Current test anchors also establish both sides independently:

• packages/runtime-host/src/__tests__/goal-coordinator.test.ts asserts that a paused Goal retains Host residency.
• packages/runtime-host/src/__tests__/host-kernel.test.ts asserts that incompatible replacement is blocked while resident.
• packages/cli/src/runtime-host-tui-command.ts retries blindly after a fixed two-second delay.

Scope

Keep Runtime Host as the sole owner of durable Goal state, residency, and admission. Do not make a Client kill, replace, or mutate a Host merely because its version differs.

Improve the local CLI/TUI conflict projection so it:

1. distinguishes an ephemeral Host that is blocked by residency from an idle Host that may exit;
2. shows safe registration facts already available to the local owner (at least PID, lifecycle mode, and Host compatibility epoch);
3. states that waiting only helps if the Host is expected to exit, and does not silently loop without feedback; and
4. directs the user to resume the prior compatible Client to inspect or clear durable work, or to make an explicit operator decision to stop the Host after checking that interruption is acceptable.

A future compatibility/skew contract is out of scope here; track that separately in #3204. Direct Goal control is tracked by #3023.

Acceptance criteria

• A residency-blocked version conflict does not present an unqualified blind wait loop.
• The message includes the relevant, safe local Host registration facts.
• Tests cover an old Host with blocked_by_residency, an idle/waitable replacement case, and cancellation.
• No incompatible Client is admitted to a Domain operation and no second Host owner is introduced.

AI assistance disclosure

This report was investigated and drafted with Codex. The reproduction, process registration, persisted Goal state, and source behavior were rechecked locally.

简体中文

问题

本地升级 Maka 后，即使没有存活的 Desktop 或 TUI，也可能被旧 Runtime Host 阻塞。当前 TUI 对所有 RUNTIME_HOST_RESTART_REQUIRED 都显示 Wait and try again, or cancel? [W/c]；输入 W 只会每两秒重试同一个不兼容握手，没有进度或原因。

典型场景是 paused Goal：非终态 Goal（包括 paused）会按设计保留 Host residency。原 Client 退出后，旧 Host 仍是 State Root 的唯一 writer；新 Client 又不能跨 compatibility epoch 发送 Domain command，因此既无法检查也无法清理该 Goal。仅等待不会让 paused Goal 自动结束。

范围

不改变 Runtime Host 对 durable Goal、residency 和 admission 的唯一 authority，也不因版本差异让 Client 自动 kill、replace 或 mutate Host。

改进本地 CLI/TUI 的冲突呈现：区分 resident 与可退出的 Host；展示安全的 registration 事实（PID、lifecycle、epoch）；明确等待只在 Host 会退出时有效；引导用户使用旧兼容 Client 检查/clear 工作，或在确认可中断后显式停止 Host。版本偏差契约仍由 #3204 讨论，Goal control 由 #3023 跟踪。

Generated-by: Codex