docs(05): 锚点补记八——分享路径设备验证成绩单（文本热/冷启动、超长走文件三条通过；图片受阻于工具）+ W37 说明 + 三条新环境坑（黑屏/adb root 冲掉 reverse/system_server 崩）+ 并行误标问题的取证结论

把「adb 造不出带授权的 URI intent，别再花时间」与「黑屏会让 input tap 全部落空、先确认屏幕是亮的」写成纪律。

devdocs/05-开发进度与交接.md

@@ -745,3 +745,46 @@ curl -s -X PATCH "$BASE/api/v1/sessions/$SID" -H "Authorization: Bearer $TOK" \
 > - 假后端**用完即关**（本次已关，18099 已释放）；别长期占 18080/18081/18083/18099。
 > - worktree 纪律照旧（合并当场 `rm -rf` + `prune`）；本批 W35/W36 都已执行，`git worktree list` 只剩主树。
 > - **动 `02` 之前先 `git status`**：本批 `02` 一直带着后端会话的在途追加，处理手法 = 先存他们的补丁 → `git checkout --` 还原 → 只提交我的 → 再把他们的贴回末尾。两边都没丢。
+
+> ## ★★ 锚点补记八（2026-10-05 傍晚 · 分享路径设备验证的成绩单 + W37 + 三条新环境坑）
+>
+> ### 状态
+> - `android` = `origin/android` = **`a2350a6`**（含 W37 的合并提交），**1084 测试 / 0 失败 / 0 错误 / 0 跳过**（主树实测）。
+> - W37 `6cdf111`（分享：认下字符串形态的 `EXTRA_STREAM` + 消灭静默失败）已合并、已推送、**worktree 已清**。
+> - `02` 里已回后端**回执十九**（`0764bc2`）：给出那次分享失败的**精确时间锚点**与「无 `error` 帧 ⇒ 帧根本没发出」的证据链。
+>
+> ### ✅ 分享路径：三条通过
+> | 场景 | 结果 | 证据 |
+> |---|---|---|
+> | 纯文本・**热启动**（连接正常） | ✅ | 库内 `clientMsgId=share-5f65cb44…` + 正文 `share one`；气泡挂 **`[用户分享]`** 角标 |
+> | 纯文本・**冷启动** | ✅ | App 被 ANR 杀掉后由分享冷启动，`share two` 照样落库（`share-ea81310c…`） |
+> | **超长正文（4200 rune）→ 文件** | ✅ | 后端 `POST /api/v1/documents 201`；库内 `content_len=0`、`documents=[{…txt, size:4200, chars:4200, status:"extracted"}]`；她回「人家打开你发来的那个文件了」 |
+>
+> ### ⛔ 分享路径：**图片（单图/多图）没拿到设备证据** —— 原因是工具，不是产品判定
+> **`adb shell am` 造不出「带授权的 URI 分享」**，两条都试过：
+> - `--esa`（`String[]`）：类型不对 ⇒ `Cannot cast [Ljava.lang.String; to android.net.Uri`（**W37 已让它不再静默**）；
+> - `--eu`（单 `Uri`）+ `-f 0x00000001`：**没有 ClipData ⇒ 授权传不到目标应用** ⇒ App 打不开那个 `content://` ⇒ 静默无反应（同一处缺陷）；
+> - **`am` 帮助里确认没有 ClipData 选项**（只有 `--eu/--esa/--grant-*`），所以这条路在 adb 上封死。
+> **真路径**是：相册（或任何真实发送方）→ 分享面板 → Cyrene。我试过，但今天 UI 驱动不可靠（见下面三条坑 + 模拟器 `system_server` 崩过一次）。
+> ⇒ **要么主人在真机上装最新 debug APK 试一次「相册多选 → 分享」，要么等下次环境稳定再做**。**不要再花时间用 adb 造 URI intent。**
+>
+> ### 🔧 W37 修了什么（都是今天实机暴露的）
+> 1. **字符串形态的 `EXTRA_STREAM` 现在认了**（`String[]` / `ArrayList<String>`，历史遗留与跨壳应用常见），**只接受 `content://`**（`file://`/`http(s)://` 一律拒，理由写在 `stringStreamUri` 的 KDoc）；非法项逐条跳过，不整体失败。
+> 2. **消灭静默失败**：`EXTRA_STREAM`/`ClipData` 里**确实有内容迹象**却一条都读不进来 ⇒ 给一条**柔和告知**「这次分享的内容没能读进来，没有发送任何内容…」（刻意不写「发送失败」）。
+>    **边界**：`EXTRA_TEXT` 与 `EXTRA_STREAM` 都为空 ⇒ **仍然静默**（两条判据同源）。
+>
+> ### ⚠️ 今天新踩的三条环境坑（比代码更耽误时间）
+> 1. **模拟器会自己黑屏**，而 `svc power stayon true` **不一定挡得住**。后果极坏：黑屏下的 `input tap` 全部落空 ⇒ 我会误判成「点了没反应 / 长按不生效 / 焦点乱跑」。**开测前先 `input keyevent 224` + `82` 唤醒并截图确认屏幕是亮的**，另加 `settings put system screen_off_timeout 1800000`。
+> 2. **`adb root` 会重启 adbd，把 `adb reverse` 全部冲掉**。之后 App 就「无法连接到服务器」。**`adb root` 用完必须补回 `adb reverse tcp:10942 tcp:10942`。**
+> 3. **模拟器的 `system_server` 会崩**（症状：`Can't find service: window`、`am` 报 `Failure calling service activity: Broken pipe`、负载飙到 11）。**此时除了重启模拟器没有别的办法**；别把这类现象当 App 的问题。
+>
+> ### 📌 主人问的「开了并行之后连串行消息都成了并行处理？」—— 结论：**不会**，今天的数据里也没有发生过
+> 三条证据：
+> 1. **服务端有硬门**：`session_orchestrator.go:300` 的 `if st.mode != ModeIdle` —— **会话空闲时根本不进并行分支**，无论客户端声明什么都不可能开第二路（空闲只有一条串行路）。
+> 2. **客户端只在忙时声明**：`parallelForSend(mode, busy) = busy && mode.wireParallel`（`InterruptScope.kt:65`），空闲时三档**逐字节相同**。
+> 3. **今天全部日志（含轮转备份）里 `parallel leg started` 只有 1 条**：`turn-4743035881e410af leg=2 active_turns=2`（`11:56:39`）—— 正是我做并行实测时**故意**制造的。
+> ⇒ **最可能的真相**：主人手机上装的是 **W36 之前**的 APK，于是**任何会话的第 2 条及以后的消息**都会被误挂「并行路 N」（`leg` 是「本会话第几条路」，不是并行与否）——**已修为 `39a63f8`，请装最新 debug APK 再看**。
+> ⇒ 若看到的其实是**底栏那句**「正在思考… 并行 N 路」：那句来自 `ChatUiState.activeTurns > 1`（`ChatScreen.kt:863`），是**另一个信号**；服务端 `session_idle` 用 `busyPayload(…, ModeIdle, 0)` 发 0（`session_orchestrator.go:455`）⇒ 正常情况下会清掉。**若仍能看到，请告诉我，我按 activeTurns 陈旧这条线单独查。**
+>
+> ### 最新 debug APK
+> `app/build/outputs/apk/debug/app-debug.apk`（由 `a2350a6` 构建；**含 W35 分享角标 / W36 角标闸 / W37 字符串形态与告知**）。