feat(chat): 大图改走 /upload，历史里只留 URL

服务端把 `chat.image` **原样落库**，于是内联的 base64 会在**每一页历史**与**每一次
WS `history` 回放**里重传一遍（协同 G3）。B1 的 `POST /api/v1/upload` 早就有了，客户端
一直没用——本次把它接进发送路径。

- `data/api/UploadApi.kt` / `data/api/dto/UploadDto.kt` / `data/repository/UploadRepository.kt`：
  upload 三件套。multipart 字段名 `file`（Go 只认这个名，且只把带 `filename` 的部件当文件，
  已对着在线后端实测：字段名不对回 `400 {"code":"bad_request","message":"file is required"}`）；
  走 `apiCall`（这台端点的状态码不承载额外语义，`413`/`415` 的区分在 `error.code` 里）。
  仓库另拦两种「服务端帮不了」的情况：`url` 为空**或不是绝对 http(s) 地址**就判解析失败
  ——视觉层只把 `http(s)://` 当 URL，裸路径会被当成 base64，照发等于把这一轮扔进黑洞。
- `app/AppContainer.kt`：按 baseUrl 缓存接线，与 chatApi 同源（上传产物 URL 必须交给同一个后端）。
- `domain/chat/ChatImageDelivery.kt`：内联 vs 上传的**唯一判据**（纯函数）。
  阈值为重编码后的 **64 KiB（含等于内联）**：内联的代价是每次历史取数再多 4/3 × B，
  64 KiB 即 +85 KB/次（20 张这种图的会话每次冷启动/重连回放就多传 ≥1.7 MB），而上传只是
  多一次往返（局域网毫秒级）——从第二次取数起就稳赚；≤64 KiB 的缩略图省下的量与一次往返同量级，
  不值得多一个失败面。阈值必须严格小于本端 1 MiB 预算，否则上传分支是死代码（有测试钉住）。
- `ui/chat/ChatViewModel.kt`：图片发送路径分流（小图内联、大图上传换 URL 再发 REST）。
  **上传失败不回退内联**：回退会把「省历史重量」当场作废、还是在用户看不见时换了一条语义不同的路；
  这里按上一步骤给可重试文案，并把图与文本还给输入框（`uploadFailureMessage`，纯函数可单测）。
- `data/image/ChatImagePreparer.kt`：产物改为同时给出 `data:` URI 与**同一份**字节，
  上传因此不必把刚编出来的东西再 base64 解一遍。

阈值依据、以及「URL 形态到底受不受 5 MiB 上限约束」的核查结论写在 `ChatImageDelivery`
与 `UploadRepository` 的注释里（结论：URL 形态**不受**解码后 5 MiB 约束——网关
`checkChatImageSize` 量的是 `image` 字符串长度，URL 才几十字符；URL 到视觉层才被取回，
上限是 `vision.maxFetchedBody` = 50 MiB。所以走上传**不是**为了绕开上限，本端 1 MiB 预算离
两个 5 MiB 上限都还差两个数量级）。

测试：309 全绿（272 → +37）：上传响应/错误体的真实形状（错误体是在线抓包原文）、
multipart 线级形状（部件名、filename、字节原样）、内联阈值与两条不变量、上传失败文案。
`assembleDebug` 通过。**未实测**（本端无模拟器、且不给在线后端留测试文件）：
真机上的上传成功链路与 Coil 渲染远程 URL——已静态确认 `coil-network-okhttp` 带
`META-INF/services/coil3.util.FetcherServiceLoaderTarget`（默认 ImageLoader 会自动注册网络
fetcher）、`network_security_config` 放行明文（同源 http URL 可取），但没跑过真机。

app/src/main/kotlin/top/yeij/cyrene/ui/chat/ChatViewModel.kt

@@ -11,10 +11,12 @@ import kotlinx.coroutines.flow.update
 import kotlinx.coroutines.launch
 import kotlinx.coroutines.withContext
 import top.yeij.cyrene.app.AppContainer
+import top.yeij.cyrene.core.error.CyreneError
 import top.yeij.cyrene.data.api.CyreneException
 import top.yeij.cyrene.data.api.dto.ChatRequest
 import top.yeij.cyrene.data.api.dto.HistoryMessageDto
 import top.yeij.cyrene.data.image.ChatImagePreparer
+import top.yeij.cyrene.data.image.PreparedImage
 import top.yeij.cyrene.data.repository.ChatAck
 import top.yeij.cyrene.data.repository.MessageRepository
 import top.yeij.cyrene.data.repository.historyForSession
@@ -23,7 +25,9 @@ import top.yeij.cyrene.data.ws.ChatSocket
 import top.yeij.cyrene.data.ws.WsEvent
 import top.yeij.cyrene.data.ws.WsState
 import top.yeij.cyrene.data.ws.isForSession
+import top.yeij.cyrene.domain.chat.ChatImageDelivery
 import top.yeij.cyrene.domain.chat.ChatSendRouting
+import top.yeij.cyrene.domain.chat.ImageDelivery
 import top.yeij.cyrene.domain.chat.SendChannel
 import top.yeij.cyrene.domain.parse.ParsedBubble
 import top.yeij.cyrene.domain.parse.StreamingContentParser
@@ -219,6 +223,9 @@ data class ChatUiState(
  *
  * 上行两条通道（路由见 [ChatSendRouting]）：短文本走 WS `chat` 帧，长文本 / 任何图片走
  * REST `POST /api/v1/chat`（`stream:true`）——**收都在 WS 上**，所以两种发的体验一致。
+ * 图片在 REST 之前还多一层选择：小图内联成 `data:` URI，大图先 `POST /api/v1/upload`
+ * 换 URL 再发（见 [deliverImage]）——服务端把 `image` **原样落库**，内联的字节会在每一页
+ * 历史与每一次 `history` 回放里重传，上传是唯一能把这个成本买断的手段。
  *
  * 本 VM 只收**属于 [sessionId] 的帧**（见 [onEvent] 的会话闸）。服务端广播不按会话订阅，
  * 且每个会话各有一个 VM（各自的 socket 都还活着），没有这道闸就会串台。
@@ -287,7 +294,9 @@ class ChatViewModel(
      * 回来**（同一个编排器 + 广播路径），所以「REST 发、WS 收」不牺牲流式体验。
      *
      * 图片先在本端解码 / 缩放 / 重编码（[ChatImagePreparer]），这一步是重活，放在 IO 线程上；
-     * 气泡同步上屏，所以等待期间用户已经能看到它。
+     * 气泡同步上屏，所以等待期间用户已经能看到它。重编码之后再按体积决定**内联还是上传**
+     * （见 [deliverImage] 与 [ChatImageDelivery]）——大图宁可多走一次 `POST /api/v1/upload`，
+     * 也不把几 MB base64 永久留在每一页历史里。
      */
     fun send() {
         val snapshot = _state.value
@@ -324,7 +333,30 @@ class ChatViewModel(
                 if (!sent) rollback(localId, "发送失败，请重试")
             }
 
-            SendChannel.Rest -> sendViaRest(localId, text, image)
+            SendChannel.Rest -> if (image == null) {
+                sendViaRest(localId, text, image = null)
+            } else {
+                deliverImage(localId, text, image)
+            }
+        }
+    }
+
+    /**
+     * 一张图怎么送上去：小图内联成 `data:` URI，大图先上传、再把返回的 URL 当 `image`
+     * （阈值与这笔成本账见 [ChatImageDelivery]）。两者都走 REST `stream:true`，收都在 WS 上。
+     *
+     * **上传失败不回退内联**：回退等于把「省历史重量」这件事当场作废——用户以为发的是 URL、
+     * 落库的却是几 MB base64，而且是在他看不见的情况下换了一条语义不同的路。这里与
+     * [ChatImagePreparer] 同一纪律：宁可回滚、把图和文本还给输入框让用户重试。
+     */
+    private suspend fun deliverImage(localId: String, text: String, image: PreparedImage) {
+        when (ChatImageDelivery.forPreparedBytes(image.bytes.size)) {
+            ImageDelivery.Inline -> sendViaRest(localId, text, image.dataUri)
+
+            ImageDelivery.Upload -> container.uploadRepository
+                .uploadImage(image.bytes, image.mime)
+                .onSuccess { uploaded -> sendViaRest(localId, text, uploaded.url) }
+                .onFailure { e -> rollback(localId, uploadFailureMessage(e)) }
         }
     }
 
@@ -667,5 +699,24 @@ class ChatViewModel(
 private fun Throwable.userMessage(): String =
     (this as? CyreneException)?.error?.userMessage ?: "加载失败，请稍后重试"
 
+/**
+ * 上传失败的文案（纯函数，可单测）。
+ *
+ * 前两条是服务端的**机器可读**拒绝码（对着在线后端实测过，见 `UploadDtoRealPayloadTest`）：
+ * 在本端预算下它们不该出现（重编码出口 ≤ 1 MiB，类型非 png 即 jpeg，都在白名单里），
+ * 但真出现时正确的动作是「换一张图」而不是「重试」，文案必须把这两者分开。
+ *
+ * 其余（网络 / 超时 / 5xx）用既有错误口径，并**点明是上传这一步**失败——否则用户看到
+ * 「无法连接到服务器」会以为整条消息没发出去，而实际上文字也是跟着一起回滚的。
+ */
+fun uploadFailureMessage(e: Throwable): String {
+    val error = (e as? CyreneException)?.error
+    return when ((error as? CyreneError.Server)?.code) {
+        "payload_too_large" -> "图片超过服务端 5 MB 上限，请换一张更小的"
+        "unsupported_media_type" -> "服务端不接受这张图片的格式，请换一张"
+        else -> "图片上传失败，" + (error?.userMessage ?: "请重试")
+    }
+}
+
 /** 思维链在流式结束后继续保留的时长。 */
 private const val THINKING_LINGER_MILLIS = 10 * 60 * 1000L