feat(serial): TX write-behind 发送队列 + 背压与失败上报

[Gyanano]

背景

在 RFC #3 Step 2 的人工硬件测试中暴露：115200 波特率下以 100ms 周期发送 2560 字节（需求 25.6 KB/s > 线路容量 11.52 KB/s），send_data 的 write_all 在内核 TX 缓冲区写满后阻塞超过端口 50ms 超时，前端弹出 Failed to send data: Operation timed out。

已在 PR（feature/tx-send-guard）中做的缓解：

• POSIX 写句柄超时 50ms → 1000ms（每次 poll 独立计时，临界速率 + 突发更平滑）
• SendPanel 周期发送速率预警（超过线路容量 90% 时提示）

本 issue 跟踪剩余的专业化改造。

现状问题

1. 无 TX 缓冲队列：send_data 在调用线程上同步 write_all，速率超限时要么报错要么阻塞堆积（Tauri command 排队），用户无法感知积压深度。
2. 部分写失败无法安全重试：write() 返回 TimedOut 时不携带已写字节数，盲目重试会重复发送字节——协议层面灾难。
3. Windows 平台约束：try_clone 走 DuplicateHandle，读写句柄共享 COMMTIMEOUTS，写超时无法独立调大（POSIX 无此问题，超时存于每个 handle 结构体）。

方案方向

• 专用 writer 线程 + mpsc 通道：send_data 只入队，writer 线程用长超时阻塞写出。
• 背压：队列容量有界，接近满时通过事件（依赖 RFC RFC: 串口核心深化重构 —— 订阅式帧通道替代轮询，面向 Agent 可编程控制 #3 Step 4 的 serial:// 事件推送）通知前端显示 TX 积压量；写失败同样以事件上报。
• 失败语义：整包要么完整入队要么拒绝（队列满），writer 失败时丢弃该包并上报，不做盲目重试。
• QuickCommandPanel 的循环发送补上与 SendPanel 相同的速率预警。

依赖

• RFC RFC: 串口核心深化重构 —— 订阅式帧通道替代轮询，面向 Agent 可编程控制 #3 Step 4（事件推送）——积压/失败事件需要它作为通道。