device-link：从共享长连接补丁转向可恢复会话与分层传输

## 背景

近期本机 device-link 日志显示，连接问题已经不是单一握手 bug。当前日志需要区分两类：

- **传输层抖动，不一定等于用户故障**：heartbeat miss、短暂 ACK timeout、WebSocket 缓冲区/背压告警中，有一部分会在很短时间内恢复，期间没有用户操作失败。
- **已经会放大成用户可见故障**：共享 relay socket 被心跳或连接级恢复拆掉、1013 inbound backpressure 后立即重连并重放、订阅重放失败、请求持续超时。这些会表现为手机转圈、设备看似在线但无法操作，或多个控制端一起受影响。

## 已确认的结构性问题

1. 被控端与 relay 之间是一条共享连接，同账号多个控制端共用，连接级动作的故障半径大于单个 peer。
2. transport heartbeat 目前仍可能直接关闭共享 socket；heartbeat 日志本身不是用户故障，但这个恢复动作会把它放大成用户故障。
3. 重连后的恢复仍以重新建立 link、补订阅和重放 pending 为主，缺少统一的持久 session/position 断点。
4. 控制帧、用户请求、实时镜像和大块推送共享出站容量，relay 背压时恢复动作可能重造触发条件。
5. UI 对 transport online、peer 可响应和数据新鲜度的表达仍不够分离，短暂恢复过程容易被用户理解成“设备离线”。

## 长期方案

### A. 可恢复会话

- 每个 peer 保存 session id、resume token、发送/接收序号和最后应用位置。
- 重连优先 Resume，只补增量；游标失效时才要求 reset + snapshot。
- 订阅、消息和状态投影统一使用位置断点，避免每次重连全量重放。

### B. 故障半径隔离

- 单请求失败只影响请求。
- 单 peer ACK 超时只重置该 peer link。
- 只有 relay 真正断开才进入连接级恢复。
- 一个休眠控制端不能拖垮同账号其他控制端。

### C. 控制流/数据流隔离与流控

- 控制帧、用户请求和最终结果高优先级。
- 实时活动、进度和可替代镜像允许合并、延迟或丢弃旧帧。
- 每 peer 有独立 credit、队列和恢复预算。
- 1013 背压后先冷却、降速，再逐步恢复，禁止立即全量重放。

### D. 路径和产品体验

- 评估 LAN/直连优先、relay 兜底和路径平滑切换。
- UI 分离“传输已连接、设备可响应、数据是否新鲜、操作是否已送达”。
- 断线期间保留本地投影，操作进入 outbox，用户只在真实业务失败时看到错误。

## 验收标准

- 短暂网络抖动不会清空当前页面或把所有 peer 一起判为不可用。
- 一个控制端休眠或停止 ACK 时，其他 peer 的请求和 link 不受影响。
- 重连优先补增量，不制造全量恢复洪峰。
- relay 背压期间用户命令和最终结果优先于活动镜像。
- heartbeat miss 只有在造成真实业务失败时才进入用户可见故障统计。

## 与止血 PR 的关系

当前止血 PR 只处理共享连接在短暂抖动下的误放大和恢复洪峰，不改变 wire protocol，不实现完整 session resume。长期方案在本 issue 继续拆分和推进。

Start by mapping the current device-link shared connection, relay recovery, peer links, and UI connection-status paths; the issue names no files or tests. Break the long-term plan into scoped work around resumable sessions, failure-radius isolation, flow control, and status separation. Done means meeting the listed acceptance criteria without implementing the whole plan in one change.

Written by the indexing model from the issue text.