AskaEth
22d655b73b
fix(chat): 分享面板的高度上限出口补上「非有限值」守卫（W61 分享全链路复核）
主人报「网易云分享文本到 App 会闪退」。已修的那个 P0（df7b504 / 6d4f2cd：面板一打开就崩 /
点展开又崩）是 Dp.Infinity 当哨兵值与展开态没去掉 verticalScroll，那是**最可能**的成因。
这一批把这**整条链**（Manifest 的 intent-filter → ShareIntake → 落地面板 → sendConfirm →
气泡渲染）从「假设主人的包就是当前 HEAD」重审了一遍，找残留崩溃点。
结论：**当前 HEAD 这条路径我没有找到残留崩溃点**。逐项复核见下面「查了什么」。审查中发现
一处**不变量只写在 KDoc 里、实现并不保证**的地方，本批把它补实（不改变任何现状行为）。
改了什么（最小的一处 + 一处 KDoc 更正）：
1. `shareConfirmWindowCap` 从纯透传改成**守卫式**：`measured` 非有限（`Dp.Infinity` / `Dp.Unspecified`
即 NaN）时与「还没量到」同等对待，回落 150dp。它上面那段 KDoc 一直写着「返回值永远不是
Dp.Infinity」，而实现是 `measured ?: 150.dp` —— 今天唯一的调用方传的是 null 或
`getLineBottom(...).toDp()`（恒有限），所以**现状没有可触发的崩溃**；但那条不变量此前只由
「调用方的好习惯」保证，而它正是 W58 崩过两次的那一条。补守卫之后可以给出一句可证明的话：
这一层给出的上限**恒有限**，于是面板里那两个 `verticalScroll`（外层预览区 / 收起态正文窗）
在任何输入与状态下都不可能落在无界高度上。
2. `ShareConfirmBody` 那段 KDoc 里一句不准确的话改准：旧文说该函数的出口「要么返回 null（不设
上限）」——它恒返回 Dp，「不设上限」发生在展开态那一支（连 verticalScroll 一起去掉），与它是两回事。
新增测试：
- `ShareTextPipelineTest`（12 例，新文件）：把「分享一段文本进来」这条链从 Intent 字段一路串到
气泡正文（`ShareRules.extract` → `shareConfirmPreview` / `shareConfirmBody` / `shareConfirmCanSend`
→ `parse`），此前**跨层串测完全空缺**（每一站各自有单测，没有一处把它们接起来）。钉三件事：
①**内容一字不丢**（「分享单曲 + 链接 + emoji + 多行」逐字节到气泡正文；用户补的描述同样）；
②**正文里的标记按既有语义走且绝不抛异常**（`<p><p>` / `<action>` / 全角半角星号 / `1 < 2` /
半个代理对 / `\u0000` / 200 个落单 `<p>` / 10 万字符都过一遍）；
③**面板预览不过解析器、气泡过解析器**（同一段带标记的字，预览里是原样、气泡里被剥离——
这是如实记下的一处不一致，不是崩溃）。
- `ShareConfirmTest`：把 `Dp.Infinity` 与 `Dp.Unspecified` 放进「任何输入都给不出非有限上限」的
输入表——原先那张表**恰好漏掉了唯一能推翻该断言的两个值**。反证过：把实现改回纯透传时，
这一条用例确实 FAILED（`no input can produce a non finite cap`），改回守卫后通过。
查了什么（逐项，都是读代码 + 纯函数求证，不是猜）：
① Intent 形态：`getCharSequenceExtra` 对非 CharSequence（`String[]` / `ArrayList`）是**catch 住
ClassCastException 回 null**（SDK 源码 `BaseOs/BaseBundle.getCharSequence` 已核），不抛；
EXTRA_STREAM 走原始值按形态分派；字符串形态只认 `content://`；ClipData 纯文本条目只当
「带着内容迹象」用来出告知。② 空/边界输入：空串 / 纯空白 → `worthDelivering=false` 静默
（正确）；`<p><p>` / 星号 / `<` 一律不抛（新用例钉住）。③ 面板渲染：Miuix 的 `WindowDialog` /
`TextField` 里**没有**任何 scroll 节点（反编译 `miuix-ui-0.9.3` 的 class 查过），面板里的两个
`verticalScroll` 各自都先过一层有限的 `heightIn`。④ 出队闸门：闸门在 `take()` 之前、认领落在
VM 状态里，重建不会再取；`claimSharedContent` 只有 Compose 主线程一个调用点。⑤ 发送后渲染：
`parse` 的落单标签口径（W55）与既有契约一致，新用例把分享正文含标记时的落点一并钉住。
⑥ 通知/保活：分享落地与 `ProactiveFrameIntake` / `KeepAliveService` 之间没有任何联动路径。
没覆盖 / 只能上真机的：渲染层本身（本模块没有 Compose UI 测试依赖，`checkScrollableContainerConstraints`
那一类崩溃单测抓不到——W58 的教训），以及任何需要设备的观感；本批**没有**装包上机（emulator-5554
上有别的会话在跑，主仓在我复核期间刚构建过 APK，我刻意没有动它）。
真跑：`./gradlew.bat assembleDebug` 通过；`./gradlew.bat testDebugUnitTest` 全量
**115 suites / 1400 tests / 0 skipped / 0 failures / 0 errors**（基线 114 / 1388，差的正是本批
新增的 1 个 suite 12 例，其余一条没碰坏）。