AskaEth
4fe5509c24
W61 分享路径审查登记的那个缺口：有些发送方不填 `EXTRA_TEXT`，内容只在
`EXTRA_SUBJECT`（少数在 `EXTRA_TITLE`）里，而本端只读 `EXTRA_TEXT` ⇒ 那次分享
**整条静默**：用户点了分享，界面毫无反应、后端零请求，连 `contentUnreadable`
那条「读不进来」的告知也够不着（它的判据里没有这两个 extra）。
改动（按主人拍板的方向）：
1. **回落链**：`EXTRA_TEXT` → `EXTRA_SUBJECT` → `EXTRA_TITLE`，取第一个非空白的
当正文（归一化口径与原来取 text 时完全一致）。`EXTRA_TEXT` 非空时它一定赢 ⇒
既有情形逐字不变（`ShareTextFallbackTest` 有专门的用例钉住这一点）。
2. **来源如实登记**：`SharedContent.textSource`（`ShareTextSource.Text/Subject/Title`）
记下正文是从哪个 extra 来的；渲染层据此说一句「这段文字来自对方的分享标题
（对方没有提供正文）」——回落来的正文与真正文长得一模一样，用户只能靠这一句分辨。
⚠️ 那句话只出现在界面上，**绝不进正文**（面板预览与发出去的消息逐字相同，有用例钉住）。
面板那边的接线需改 `ShareConfirmPanel.kt`（本批的**红线**：另一支正在改它），
所以这一句先挂在**认领那一刻**的柔和告知通道上（`ChatViewModel.claimSharedContent`
→ `showShareNotice`）：它必须在用户点「发送」之前说。
3. **三个 extra 都空 / 都读不出来 ⇒ 走「读不进来」告知，绝不静默**：判据加了
`textPresent`（「三个里至少一个躺着原始值」由读了原始值的那一层报进来，与既有的
`streamPresent` 同一个形态）。「连值都没有」（误触分享）照旧静默 —— 边界没放宽。
4. **读取防御式**：四个 extra 统一读**原始值**再按形态分派（`Intent.rawExtra`，带
`runCatching`）。核对过 AOSP `android/os/BaseBundle.java`：`getCharSequence` 自己
catch `ClassCastException` 回 null（**类型不符不抛**），会抛的是 `unparcel()` 的
`BadParcelableException`（畸形 bundle）——那一路由 `runCatching` 挡住，不让异常从
`accept` 冒出去。不引入新依赖，UI 侧零新增控件。
测试：新增 `ShareTextFallbackTest`（11）、`ShareTextExtrasTest`（8）、`ShareNoticeTest` +4；
全量 testDebugUnitTest 123 suites / 1494 tests / 0 failures / 0 errors
（基线 121/1471/0/0）；`assembleDebug` 通过（--no-build-cache 真跑）。