fix(peer): keep Mesh and shared-session routes live

[M4n5ter]

English

Summary

Keep Peer Mesh and Session collaboration reachable through the running Runtime Host's live peer endpoint, recover idle connections promptly, and make durable Guest Turn requests visible wherever the Owner is working.

The failures came from independent liveness gaps that compounded:

1. persisted configuration contains startup routes, while automatically discovered Circuit Relay v2 reservations exist at runtime;
2. the native endpoint waited for a local external-address candidate before requesting or using a Relay reservation;
3. an execution-service ownership wrapper spread a getter-backed listener object and froze its startup-time empty Relay snapshot;
4. an accepted Runtime Host connection was only probed while a domain request was outstanding, so an idle dead connection could survive until the next user action;
5. a signed Mesh route could remain inside its TTL after a peer restart or Relay reservation rotation, and changed local routes were only noticed by the 30-second reconciliation cadence;
6. Desktop removed a Guest Session catalog row while its retained Runtime Host mount was reconnecting, causing owner-only panels to mount for the still-open Guest Session;
7. a Guest Turn request was durable on the Host but only visible after the Owner opened that Session's sharing dialog.

This change:

• publishes a bounded live peer endpoint through authenticated host.status;
• preserves the dynamic listener projection through the execution-service ownership wrapper;
• pins the configured Peer ID while reading current route hints and accepted Relay reservations for Local and managed remote Hosts;
• requests and uses Circuit Relay v2 reservations after Relay Identify completes, without requiring a public-address candidate first;
• probes every quiet accepted Runtime Host connection after two seconds and fails it after a further two-second unanswered status probe, handing recovery to the existing reconnect lifecycle;
• observes listener and accepted-Relay changes through the existing Mesh reconciliation task and republishes them in about one second;
• refreshes a visible peer's signed Mesh route on connection establishment even when the cached route is still inside its TTL;
• lets a self-contained explicit target dial immediately while refreshing Mesh control in parallel, and merges current Mesh routes on reconnect;
• retains a Guest Session catalog projection while its explicit shared mount still exists, without treating transport availability as authorization;
• aligns authentication and protocol handshake deadlines and reports background reconciliation failures;
• tells the Owner whether the exact invitation being copied contains a Relay reservation, and warns when it contains direct routes only;
• keeps the copy action visible in the sharing dialog footer and adds an explicit paste action without granting the renderer ambient clipboard-read permission;
• adds an Owner-wide durable Turn-request inbox, notification, persistent per-Session count, and inline exact-intent approval banner;
• keeps approval authority on the Host and queries only requests visible to the authenticated principal.

Retained Guest mounts, grants, and Session identity survive Client shutdown. After restart, the existing reconnect lifecycle re-authenticates the mount and combines its durable invitation with current signed Mesh routes. A changed direct address or Relay reservation is republished and fetched rather than requiring the Session to be shared again. Recovery still requires at least one physically reachable direct, Circuit Relay v2, or approved member-transit path; mutations with an unknown outcome are never replayed.

Compatibility epoch 89 requires the Desktop Client and Runtime Host to be updated together because host.status has an exact wire shape and the Turn-request query now supports an Owner-wide inbox.

Verification

• full Desktop tests: 1843/1843 passed
• full Runtime Host tests: 1548 passed, 12 skipped, 0 failed
• latest focused Runtime Host liveness, Mesh route-rotation, and peer-client tests: 49/49 passed
• latest focused Desktop catalog, collaboration IPC, inbox, and invitation clipboard tests: 12/12 passed
• Desktop, Runtime Host, and UI package typechecks
• Desktop preload and main builds
• renderer architecture ratchet against the latest origin/main
• Biome and git diff --check on the changed files
• cargo test --locked --manifest-path native/runtime-host-peer/Cargo.toml: 21/21 passed
• cargo clippy --locked --all-targets --manifest-path native/runtime-host-peer/Cargo.toml -- -D warnings
• real relay-only join after removing every direct route from a fresh invitation
• real independent Guest import completed invitation validation, route preparation, peer handshake, credential authentication, finalization, and Session mount
• real two-Client Turn-request flow: Guest request → Owner notification and sidebar count → notification navigation → exact-intent rejection → pending state cleared

中文

摘要

让 Peer Mesh 与 Session 协作始终使用正在运行的 Runtime Host 的实时 peer endpoint 保持可达，及时恢复空闲断连，并让持久化的 Guest 轮次请求在 Owner 当前工作的任何位置都可见。

此前有七个相互叠加的存活性缺口：

1. 持久化配置只保存启动时路由，而自动发现并成功预约的 Circuit Relay v2 节点只存在于运行时；
2. native endpoint 在申请或使用 Relay reservation 前错误等待本机先产生 external-address candidate；
3. execution service 展开了 getter-backed listener 对象，把启动时的空 Relay 快照冻结下来；
4. 已建立的 Runtime Host 连接只有存在未完成 domain request 时才会探测，空闲死连接会一直留到用户下次操作；
5. Peer 重启或 Relay reservation 轮换后，签名 Mesh 路由可能仍在 TTL 内，且本机路由变化只有 30 秒同步周期才会发现；
6. Guest Runtime Host mount 重连期间，Desktop 会删除 Guest Session catalog 行，让仍打开的 Guest Session 错误挂载 Owner-only 面板；
7. Guest 轮次请求虽已持久化在 Host，却只有 Owner 打开该 Session 的分享弹窗后才能发现。

本次修改：

• 通过已认证的 host.status 发布有界的实时 peer endpoint；
• 在 execution-service 的资源所有权包装层保留动态 listener projection；
• 为 Local Host 和受管远程 Host 固定已配置的 Peer ID，同时读取当前路由与已接受的 Relay reservation；
• Relay 完成 Identify 后即可申请和使用 Circuit Relay v2 reservation，不再要求先获得公网地址候选；
• 所有已建立连接静默两秒后主动发送状态探测，再有两秒未响应就判定失败并交给既有重连生命周期；
• 在既有 Mesh 同步任务中约每秒观察一次 listener 与已接受 Relay 的变化并及时发布；
• 每次建立连接时刷新可见 Peer 的签名 Mesh 路由，即使缓存仍在 TTL 内；
• 对自包含的显式目标立即拨号，同时并行刷新 Mesh control，重连时合并当前 Mesh 路由；
• 只要显式共享 mount 仍存在，就在暂时断连期间保留 Guest Session projection，不让传输可用性改变授权分类；
• 对齐认证与协议握手期限，并报告后台同步错误；
• 在 Owner 复制邀请码时明确显示是否包含 Relay reservation，仅有直连路径时给出警告；
• 将复制操作固定在分享弹窗底部，并提供显式粘贴操作，同时不向 renderer 开放全局剪贴板读取权限；
• 增加 Owner 级持久轮次请求收件箱、通知、Session 侧边栏计数和会话内精确 intent 审批条；
• 审批 authority 仍完全属于 Host，查询只返回当前认证主体可见的请求。

Guest Client 关机不会删除已保留的 mount、grant 或 Session identity。重新启动后，既有重连生命周期会重新认证，并把持久邀请码与当前签名 Mesh 路由合并；直连地址或 Relay reservation 变化后会重新发布和获取，无需再次分享 Session。恢复仍要求至少存在一条物理可达的 direct、Circuit Relay v2 或已批准成员转发路径；结果未知的 mutation 绝不会自动重放。

由于 host.status 是严格 wire shape，且轮次请求查询新增 Owner 全局收件箱语义，本次将兼容 epoch 提升到 89；Desktop Client 与 Runtime Host 需要一起更新。

验证

• Desktop 全量测试：1843/1843 通过
• Runtime Host 全量测试：1548 通过、12 跳过、0 失败
• 最新 Runtime Host 保活、Mesh 路由轮换与 peer client 聚焦测试：49/49 通过
• 最新 Desktop catalog、协作 IPC、inbox 与邀请码剪贴板聚焦测试：12/12 通过
• Desktop、Runtime Host 与 UI package typecheck
• Desktop preload 与 main build
• 相对最新 origin/main 的 renderer architecture ratchet
• 变更文件 Biome 与 git diff --check
• cargo test --locked --manifest-path native/runtime-host-peer/Cargo.toml：21/21 通过
• cargo clippy --locked --all-targets --manifest-path native/runtime-host-peer/Cargo.toml -- -D warnings
• 真实 Relay-only 加入：从新邀请码中移除全部直连路由后完成加入
• 真实独立 Guest 导入：完成邀请码验证、路径准备、peer 握手、Guest 凭据认证、finalize 与 Session mount
• 真实双 Client 轮次请求：Guest 请求 → Owner 通知与侧边栏计数 → 通知跳转 → 精确 intent 拒绝 → pending 状态清空

Screenshots

Owner-wide notification and persistent per-Session count while another Session is active:

Exact-intent approval at the target Session:

Invitation reachability carried by the exact copied code:

AI use

• No generative tool made a substantive contribution
• Generative tooling made a substantive contribution

Tool(s) and scope: OpenAI Codex diagnosed the connection, route-liveness, catalog-classification, and approval-discovery paths, implemented the changes, and added focused tests under maintainer direction and review.

Checklist

• Tests cover the change and fail without it
• Lint, format, typecheck and the affected suites pass locally

Does this PR entail a change in behavior?

• Yes — described under Summary above
• No

[jackwener]

Approved at exact head 62a7b3823dcb88225de30a4ecc47dd8f24831a5c at the explicit direction of M4n5ter. No technical review was performed as part of this action; M4n5ter requested the approval and accepts responsibility for subsequent handling.

---

Review notice: This approval was submitted by an automated review agent operated by WAWQAQ and is published at the direction of M4n5ter, who requested this action and is the human accountable for it.