fix(runtime-host): preserve legacy-readable profiles across new profile kinds

[M4n5ter]

English

Problem

Runtime Host profiles from different product generations currently share one versioned runtime-host-profiles.json document.

The released v0.1.11 reader accepts only schema 1 and decodes every entry as a remote profile. Current main writes schema 2 when the catalog contains either:

• a WSL environment profile; or
• an SSH profile with operator activation.

After the current client writes either entry, v0.1.11 fails closed while decoding the document. The file is not overwritten or corrupted, and reopening it with the current client works, but otherwise valid legacy remote profiles become unavailable to the older client.

This was confirmed while adjudicating the post-merge review of #4064. It is not a WSL transport or release-blocking correctness issue; it is a persistence-boundary limitation exposed by adding new profile kinds.

Desired outcome

Preserve a last-release-readable projection of legacy remote profiles when newer clients persist profile capabilities that the released reader cannot understand.

Solve this at the persistence boundary. A decoder-only change in the current client cannot help an already released binary, and silently dropping unknown entries would risk data loss.

Acceptance criteria

• After a current client adds a WSL environment, v0.1.11 can still read the legacy remote profiles it previously understood.
• The current client retains complete access to both environment and remote profiles.
• An older client cannot overwrite or erase newer-only profiles when it edits its readable profile set.
• Invalid or unsupported data still fails closed within the authority that owns it.
• The design does not introduce a long-lived cross-file transaction protocol unless a concrete consistency requirement needs one.

Non-goals

• Making v0.1.11 understand WSL or activation SSH profiles.
• Supporting concurrent mixed-version clients as a general distributed-write protocol.
• Migrating unreleased intermediate schemas.

Source: #4064 post-merge review.

简体中文

问题

不同产品代际的 Runtime Host profile 当前共用一个整体版本化的 runtime-host-profiles.json 文档。

已发布的 v0.1.11 reader 只接受 schema 1，并把每个条目都按 remote profile 解码。当前 main 在 catalog 包含以下任一条目时会写入 schema 2：

• WSL environment profile；
• 带 operator activation 的 SSH profile。

当前客户端写入任一条目后，v0.1.11 会在解码整个文档时 fail closed。文件不会被覆盖或损坏，重新使用当前客户端即可恢复访问，但旧客户端同时也看不到原本能够读取的 legacy remote profiles。

该事实是在裁决 #4064 合并后的 review 时确认的。它不是 WSL transport 缺陷，也不是发布阻塞问题；根因是新增 profile kind 暴露了持久化边界的局限。

期望结果

当新客户端持久化旧版 reader 无法理解的 profile 能力时，仍保留上一已发布版本可读取的 legacy remote profile 投影。

应在持久化边界解决。只修改当前客户端 decoder 无法帮助已经发布的二进制；静默丢弃未知条目则可能造成数据损失。

验收标准

• 当前客户端添加 WSL environment 后，v0.1.11 仍能读取它原本理解的 legacy remote profiles。
• 当前客户端仍能完整访问 environment 和 remote profiles。
• 旧客户端修改其可读 profile 集合时，不能覆盖或删除仅新版本支持的 profiles。
• 无效或不支持的数据仍在其所属 authority 内 fail closed。
• 除非存在明确的一致性要求，否则不引入长期跨文件事务协议。

非目标

• 让 v0.1.11 理解 WSL 或 activation SSH profiles。
• 把并发 mixed-version client 扩展为通用分布式写入协议。
• 迁移尚未发布的中间 schema。

来源：#4064 合并后 review。

[M4n5ter]

Closing as not planned after adjudication. The downgrade limitation is factual, but it requires a user to create a newer Runtime Host profile and then return to v0.1.11 with the same Client Data Root. Runtime Host currently has almost no real users, the failure is fail-closed without data loss, and reopening with the current client restores access. Changing the persistence boundary now would add complexity without demonstrated product value. Reconsider only after Runtime Host adoption creates an explicit downgrade-compatibility requirement.\n\n经裁决按不计划处理关闭。该降级限制在事实层面成立，但需要用户先创建新版 Runtime Host profile，再使用同一 Client Data Root 返回 v0.1.11。Runtime Host 当前几乎没有实际用户，失败会 fail closed、不会丢失数据，重新使用当前客户端即可恢复。现在修改持久化边界会增加尚无产品价值支撑的复杂度；仅在未来 Runtime Host 形成明确的降级兼容要求后重新评估。