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 个测试类）。

devtools/fake-backend/README.md

@@ -474,8 +474,11 @@ curl -s -X POST "$B/__control/messages?session=web&count=1&role=user&text=&docum
 - `out/upstream.jsonl` —— **每条上行帧一行**：`{ts, epochMs, client, type, sessionId, raw, frame}`。
   `raw` 是客户端发来的**原样文本**。「客户端到底发没发那一帧」以这里为准。
 - `out/downstream.jsonl` —— 每条下发帧：`{ts, to, origin, raw}`。`origin` 会写清是 `history`、`control:reply` 还是某次广播。
-- `out/http.jsonl` —— 每条 HTTP 请求：`{method, path, query, headers}`。
+- `out/http.jsonl` —— 每条 HTTP 请求：`{method, path, query, headers, body}`。
   `Authorization` 只留 sha256 指纹、WS 的 `?token=` 同样只留指纹 —— 就算它是假 token，也没理由把凭据原文写进可能被 commit 的文件。
+  `body` 是**请求体的摘要**，不是原文：结构照留（键、布尔、数字、数组长度），超过 200 字符的字符串换成
+  `"<N chars>"`，非 JSON 的体记成 `{bytes, note}`。这样「发了几条、每条带不带图、有没有 `parallel`」
+  读得出来，而图片的 base64 不会把一行日志撑到几 MB。`body` 只在有请求体时出现。
 
 挂起的上行消息（`--hold-replies`）**不进文件** —— 它只活在内存里，看 `GET /__control/state` 的
 `heldMessages`。`out/*.jsonl` 仍照常记「上行帧收到了什么 / 下发帧广播了什么」。