AskaEth
be1c372d99
fix(W29): stream_chunk 语义订正、空壳消息如实说明、分享长正文走文件、图片 URL 兜住 host
一、stream_chunk 由「增量」订正为「整段」（后端回执十三 §1）
后端确认三件事：生产里已无生产者、delta 是整段 res.Text、不会与结构化帧并存。
W26 那版照 message.delta 把 delta 追加进同一气泡是错的——真到达会把同一段内容追加成重影。
改法：同一回合内已经收到过结构化帧（message.start / message.delta）就整帧忽略；否则先用
StreamingContentParser.reset 清缓冲，再把这一整段喂进去，即用它整段替换当前流式气泡的正文。
兜底分支保留（后端明确不建议删：那是未知帧不丢内容的兼容路径）。顺带把「回退路径没有
message.start、所以 freshTurnIfFinished 不触发」这条边界在同一个分支里补上（一行级别的收口）。
二、空壳消息不再渲染成空气泡
主人报的 bug 根因在服务端（微信发来的文件没有挂到消息的 documents 上，content 也是空），
已登记后端；但客户端拿到的确实是一条什么都没有的消息，此前渲染成空气泡，用户只能猜。
新增纯函数 isContentlessUserMessage（role 是 user 且 content 空、无 image、无 documents、
无 thinking 才成立，任何一项有内容都不成立，assistant 一律不成立），成立时在气泡位置改为
一句如实说明「这条消息的内容没有被传过来」：灰底灰字（沿用文件里既有的灰态小字），措辞只陈述
本端确定的事实，不猜原因。判据放渲染层（MessageBubble），因为它纯属显示，服务端说什么就存什么，
不在组装层改 DTO。
三、分享进来的超长正文走文件（主人已拍板）
分享的文本超过现成的 TEXT_AS_DOCUMENT_RUNE_LIMIT 时，落成一份 .txt：写进分享缓存目录、
上传 POST /documents、随 chat.documents 发，正文那一栏留空。判据抽成纯函数
DocumentDelivery.planSharedText（正文是否超阈值 + 附件位是否还有空）。
附件位被分享进来的文件占满（一个回合 5 份）时不做转换：正文照正文发，并在提示里说清
「本想作为文件发送，但附件位已占满」——绝不为了塞下 .txt 挤掉用户明确要发的文件。
落盘失败同样退回内联并说一句。组合与图片的关系：那份 .txt 就落在正文原来所在的那一条上
（第一条带图，其余每条一张）。
明确不动的：用户自己在输入框里打的字那条路，长正文照旧按正文发（devdocs/05 的定案第 3 条），
这两件事不是同一件。
四、历史图片的同源绝对地址按当前 baseUrl 兜住 host（F6①）
POST /upload 的 url 是按请求时的 r.Host 拼的绝对地址且原样落库，换服务器地址后旧图取不回；
后端明确认可客户端做「保留 path、替换 host」。新增纯函数 ImageHostRebase.apply：只认
http(s)://任意host/api/v1/files/一段名字 这一种形态，替换 scheme 与 authority、path 逐字节保留；
第三方 CDN、data:、content:// 与 file://、相对路径、裸文件名、带查询串或百分号编码、多一段路径的
一律原样返回。渲染历史图片前在 ChatScreen 传入 AuthManager.currentBaseUrl，全屏查看拿到的也是
替换后的地址。逆作用写进 KDoc：换了指向不同数据的 host 会 404，那是诚实的失败，比永远取不回好。
不改落库数据、不改上传、不碰 documents。
测试：新增 ImageHostRebaseTest 与 ContentlessMessageTest，DocumentDeliveryTest 补分享长正文的判据；
stream_chunk 那条分支是 VM 里的状态机分支，没有硬抽成纯函数（不为测试拧弯架构），改动写在 KDoc 里。