fix(polish): 润色流式请求让取消检测和网络等待赛跑，不再悬挂到 budget 结束

[MurphyLo]

摘要

Fixes #1000。

润色阶段模型迟迟不返回时，取消要等 32~53s 才生效，期间胶囊卡死、快捷键无响应，只能强制重启 App。根因是 chat_completion_messages_streaming 里等待网络的 await 都不参与取消检测，should_cancel 只在 SSE 循环顶部被轮询一次。同类问题在转写阶段已由 #798 修过，没有推广到润色阶段。

本 PR 用同款 tokio::select! 赛跑补齐该函数里的三处网络等待，取消粒度从「最长等一个 budget」收窄到 ~75ms。

修复 / 新增 / 改进

• 新增 wait_until_cancelled（75ms 轮询，与 wait_for_processing_cancel 同间隔），分别与三处网络等待赛跑：建连 send_with_transient_retry、SSE 逐帧 response.chunk()、非 2xx 错误体 response.text()。
• 第三处是外部 review 才发现的遗漏：polish_client 用 POLISH_CLIENT_HARD_CAP_SECS（900s）作总超时，服务端只要回一个 500 头就挂住不发 body，取消完全不生效，最坏卡死 15 分钟——比原路径的 30s 首字预算严重一个数量级。
• 三处 select! 均加 biased，让取消分支先于网络分支被 poll，消掉「budget 归零与取消同时就绪时随机选分支」的竞态。
• 建连阶段取消返回的 status 由 200 改为 0：该路径上一个 HTTP 响应字节都没收到，报 200 会把日志排查带偏。
• 三个回归测试各锁一处等待点，均做过反向验证（移除对应赛跑后该用例失败）：cancellation_mid_stream_* 对应 issue 日志里 after 0 deltas ... breaking SSE loop 的真实路径；cancellation_while_reading_error_body_* 在移除赛跑后实测耗时 5.01s。
• 未改动：dictation.rs 状态机、already_streamed 语义、各项超时预算数值。
• 未改动：chat_completion_history_streaming 与 Codex OAuth 流式路径存在同款写法，不在本次复现路径内，留作单独跟进。

兼容

• 不包含：不改超时预算数值（首字 30s+ / 空闲 20s / 硬顶 900s），不改 already_streamed 语义与 dictation.rs 状态机。
• 对现有用户 / 本地环境 / 构建流程的影响：无。只缩短「点了取消后还要等多久」，未取消路径的行为不变。
• 改动量：生产代码净增 48 行（含注释），测试净增 153 行。

测试计划

• 命令：cargo test --manifest-path src-tauri/Cargo.toml --lib（macOS/aarch64）
• 结果：1227 passed; 0 failed
• 反向验证：逐个移除三处赛跑后重跑，对应用例分别失败（SSE 循环那处取消被忽略并返回 Ok；错误体那处耗时 5.01s）
• 证据路径：本地终端输出，未落盘到仓库