feat(runtime-host): support native Windows managed deployments

[M4n5ter]

English

Problem

Maka's Runtime Host core already runs on Windows, but native Windows cannot own a canonical managed deployment. Provider discovery rejects Windows, the stable operator and SSH control path assume POSIX execution, and managed package placement is not consistently Windows-native. Adding only a Windows service-manager branch would therefore expose a partial capability that cannot safely complete setup, activation, update, recovery, and uninstall.

This is a focused follow-up to #3984 and contributes to the Windows roadmap in #2142.

Desired outcome

Support native Windows managed Runtime Hosts under the current user with the same canonical deployment, exact-package, single-owner, transaction, reconciliation, and fail-closed guarantees already used on Linux and macOS.

The initial supervised guarantee must be session-scoped: the Runtime Host remains available while that Windows user is signed in. The product must not present this as machine-level availability.

Direction

• Make the stable operator and its control route platform-neutral. The contract must describe how to invoke the operator without assuming that one path is directly executable or that the target has a POSIX shell.
• Use Windows-native application-data locations consistently for deployment packages, authority records, operator artifacts, logs, and control state.
• Add a canonical per-user Windows Task Scheduler lifecycle provider. Keep the Runtime Host supervisor and scheduled one-shot reconciliation trigger as separate deterministic projections of the deployment authority.
• Use the Task Scheduler programmatic contract and Windows process-tree ownership primitives so status, PID, last exit, restart, retirement, logs, rollback, and uninstall have stable semantics independent of localized command output or shell parsing.
• Persist the selected provider and session availability. Environment changes must not silently select a different provider or downgrade to on-demand.
• Extend Windows SSH setup and operator activation without relying on the remote account's configured default shell. All framed results remain bounded, strict, and redacted.
• Reuse the existing lifecycle transaction coordinator, State Root fence/election, exact-package update flow, and Desktop binding. Windows must not introduce a second lifecycle authority or a parallel state machine.

Why this direction

Windows Task Scheduler can supervise a per-user background process, start it at sign-in or on demand, prevent duplicate instances, restart failures, expose runtime status, and trigger scheduled reconciliation without storing an account password or requiring routine elevation. Those semantics match supervised / session.

The following alternatives are intentionally rejected for the initial capability:

• A raw Windows Service: it requires a service-aware native entry point, administrative installation, and a service identity whose profile, credentials, and filesystem authority do not naturally match the interactive Maka user. It solves a different machine-availability problem.
• S4U or a hidden password-backed task: S4U restricts network and encrypted-file access, while storing a user password creates an unacceptable credential lifecycle.
• NSSM, WinSW, or another service wrapper: this adds another executable lifecycle and supply-chain dependency without fixing user-identity semantics.
• Desktop autostart as the supervisor: this would make Desktop a second lifecycle owner and leave CLI/TUI/remote management with a different contract.
• Shell scripts or localized schtasks output: these make correctness depend on quoting, execution policy, locale, and the configured remote shell.

Machine-scoped Windows availability may be designed later as a distinct, explicitly privileged provider if real demand justifies its service-account and bootstrap cost. It must not be inferred from this session provider.

Acceptance criteria

• A standard Windows user can install, inspect, start, connect to, configure, update, retire, and uninstall a native managed Runtime Host without entering an account password or silently elevating.
• The persisted provider offers exactly session availability and is not re-detected after installation.
• The supervisor launches the persisted exact package, and all activation races still converge on one State Root owner and one Runtime Host PID.
• Unexpected Host exit is supervised; stopping or uninstalling drains or terminates the owned Windows process tree without orphaning work.
• Status reports the lifecycle mode, availability, provider, PID, last exit, reconciliation trigger, and scheduled-update availability. Logs are bounded and redacted.
• Scheduled reconciliation invokes the stable operator and remains valid after an exact-package update.
• Ordinary lifecycle/update failures restore the previous eligible owner; commit-unknown and blocked states fail closed under the existing transaction rules.
• Windows SSH onboarding and subsequent operator control work with paths and arguments containing spaces, non-ASCII text, and shell metacharacters.
• Uninstall removes provider, operator, package, credential, and control artifacts while preserving the State Root.
• No compatibility or migration path is added for a Windows managed-provider format that has never shipped.

Validation principle

Keep only a few merge-changing tests:

• one Windows-native lifecycle test covering install, concurrent activation to one PID, readiness, crash restart, retirement/process-tree cleanup, scheduled reconciliation, and uninstall;
• one Windows SSH/operator test covering hostile paths and arguments plus strict framed output.

Existing platform-neutral transaction tests remain the authority for rollback and commit-unknown behavior; do not duplicate their full failure matrix for Windows.

中文

问题

Maka 的 Runtime Host 核心已经可以在 Windows 运行，但原生 Windows 目前不能承载 canonical managed deployment。provider discovery 会拒绝 Windows，稳定 operator 和 SSH 控制路径假设 POSIX 执行环境，managed package 的落盘位置也没有统一遵循 Windows 语义。因此，只增加一个 Windows service-manager 分支会暴露半成品能力，无法安全完成 setup、activation、update、recovery 与 uninstall。

这是 #3984 的聚焦后续，也属于 Windows roadmap #2142。

期望结果

让当前 Windows 用户能够运行原生 managed Runtime Host，并复用 Linux/macOS 已有的 canonical deployment、exact package、single owner、transaction、reconciliation 与 fail-closed 保证。

首个 supervised 保证必须是 session scope：只承诺该 Windows 用户登录期间保持可用，产品不得把它描述成 machine-level availability。

方向

• 将稳定 operator 及其 control route 改为平台无关契约，不再假设一个 path 可以直接执行，也不假设目标存在 POSIX shell。
• deployment package、authority record、operator artifact、日志与 control state 统一使用 Windows 原生 application-data 位置。
• 增加 canonical 的 per-user Windows Task Scheduler lifecycle provider；Runtime Host supervisor 与 scheduled one-shot reconciliation trigger 仍是 deployment authority 的两个独立确定性投影。
• 使用 Task Scheduler 的程序化契约与 Windows 进程树 ownership 原语，使 status、PID、last exit、restart、retirement、logs、rollback 和 uninstall 不依赖本地化命令输出或 shell 解析。
• 持久化已选择的 provider 与 session availability；环境变化不得静默改选 provider，也不得降级为 on-demand。
• 扩展 Windows SSH setup 与 operator activation，不依赖远端账号配置的默认 shell；所有 framed result 继续保持有界、严格和脱敏。
• 复用现有 lifecycle transaction coordinator、State Root fence/election、exact-package update flow 与 Desktop binding；Windows 不得引入第二 lifecycle authority 或平行状态机。

为什么选择这个方向

Windows Task Scheduler 可以在不保存账号密码、无需日常提权的前提下，监督当前用户的后台进程，在登录时或按需启动，阻止重复实例，异常重启，返回运行状态，并触发定时 reconciliation。这些语义与 supervised / session 一致。

首版明确拒绝以下替代方案：

• **直接使用 Windows Service：**需要 service-aware native entry point、管理员安装和独立 service identity；其 profile、凭据与文件权限并不天然属于交互式 Maka 用户。它解决的是另一种 machine availability 问题。
• **S4U 或保存密码的 task：**S4U 会限制网络与加密文件访问；保存用户密码则引入不可接受的 credential lifecycle。
• **NSSM、WinSW 等 service wrapper：**增加新的 executable lifecycle 与供应链依赖，却没有解决用户身份语义。
• **让 Desktop 自启动并充当 supervisor：**会使 Desktop 成为第二 lifecycle owner，并让 CLI/TUI/remote management 使用另一套 contract。
• **shell script 或解析本地化的 schtasks 输出：**正确性会依赖 quoting、execution policy、locale 与远端默认 shell。

如果未来真实需求足以覆盖 service account 与管理员 bootstrap 的成本，可以另行设计显式 privileged、machine-scoped Windows provider；不能从本 session provider 推断该能力。

验收标准

• 普通 Windows 用户无需输入账号密码或被静默提权，即可安装、检查、启动、连接、配置、更新、退休和卸载原生 managed Runtime Host。
• 持久化 provider 只声明 session availability，安装后不重新探测。
• supervisor 启动持久化的 exact package；所有 activation race 最终仍只有一个 State Root owner 和一个 Runtime Host PID。
• Host 异常退出会被监督；stop/uninstall 会清理所属 Windows 进程树，不遗留孤儿进程。
• status 返回 lifecycle mode、availability、provider、PID、last exit、reconciliation trigger 与 scheduled-update availability；日志有界且脱敏。
• scheduled reconciliation 调用稳定 operator，并在 exact-package update 后继续有效。
• 普通 lifecycle/update 失败恢复原 eligible owner；commit-unknown 与 blocked state 继续按既有 transaction 规则 fail closed。
• Windows SSH onboarding 与后续 operator control 能处理空格、非 ASCII 文本和 shell 元字符路径/参数。
• uninstall 删除 provider、operator、package、credential 与 control artifact，但保留 State Root。
• 不为从未发布过的 Windows managed-provider 格式增加兼容或迁移路径。

验证原则

只保留少量会改变合并判断的测试：

• 一条 Windows-native lifecycle 测试，覆盖 install、并发 activation 收敛到一个 PID、readiness、crash restart、retirement/process-tree cleanup、scheduled reconciliation 与 uninstall；
• 一条 Windows SSH/operator 测试，覆盖 hostile path/argv 与严格 framed output。

既有平台无关 transaction 测试继续作为 rollback 与 commit-unknown 行为的 authority，不为 Windows 重复整套 failure matrix。