AskaEth
8babd1d2bb
W76：把「分享批量投递零声明」提成可单测的纯函数 + 假后端 http.jsonl 记请求体摘要
两件事都是为了让「分享 3 张图 = 3 条消息、零 interrupt」这条结论有据可查——
一条是代码侧的构造性保证，一条是设备侧的证据工具。
1) ShareRules.declaresSendPreference(fromShare, index)（纯函数）
「这一次投递要不要按『她忙时发消息』偏好声明 interrupt / parallel」原先分在两处手写：
ChatViewModel.sendShared 传 false、emitPlannedMessages 里 && index == 0。两处各是半个判据、
一处都单测不到，而这条边界正是 W25 修掉的「分享多图自相打断」（第 2 张把第 1 张刚起的回合
打掉，见 02 的 F4 与 05 那一节）。提成一处判据后语义不变，穷举整批（0..MAX_IMAGES-1 及越界）
由 ShareSendDeclarationTest 钉住：分享恒 false、手打只在第 0 条 true。
ChatViewModel 不在本次 scope，接线那一行没动（已作为 finding 上报，纯函数暂为唯一出处）。
2) 假后端 out/http.jsonl 记请求体摘要（不只是 headers）
分享多图走 REST 不走 WS（ChatSendRouting.channelFor：hasImage ⇒ Rest），所以「发了几条、
每条带的是正文还是图、有没有 parallel」只能从 HTTP 流水里读。此前它只记 headers，
现在加 body 摘要：结构照留（键 / 布尔 / 数组长度），超过 200 字符的字符串换成 <N chars>，
非 JSON 记 {bytes, note}——图片的 base64 只留长度，不会把一行撑到几 MB。
_read_body 顺带加了缓存：body 只能从 rfile 读一次，先记录再让 handler 读会得到空串。
assembleDebug + testDebugUnitTest 全绿：1674 测试 / 0 失败 / 0 错误 / 0 跳过（134 个测试类）。