refactor(serial): Step 2 读循环瘦身 + 帧硬切块

[Gyanano]

RFC #3 Step 2：读循环瘦身 + max_frame_bytes 硬切块

跟踪 issue：#3（前置：#4 CI 安全网、#5 FrameSegmenter 抽取）

改动

• serial_manager.rs：connect() 读循环 ~330 → ~120 行。原先 4 处复制粘贴的产出块（text 录制 → display 格式化 → LogEntry push+trim → stats）合并为单一 emit_frame 闭包，分帧决策全部委托给 FrameSegmenter。
• framing.rs：新增 max_frame_bytes 硬上限（DEFAULT_MAX_FRAME_BYTES = 64 KiB）。连续无分隔符数据流在 feed() 内按上限切块，不再无限积累等空闲间隙；分隔符在上限窗口内仍优先成帧。64 KiB 对齐 Step 4 规划的 IPC 批量预算。

唯一有意的行为变化

单帧不再可能无限大：> 64 KiB 的无分隔符连续数据会被切成 64 KiB 大小的帧。Raw 文件 tap 位置不变（分帧前写入），录制内容不受影响。

验证

• cargo test 32/32 全绿：28 个基线 + 3 个新硬切块单元测试 + 1 个 harness 测试（150 KiB 连续流 → 65536+65536+22528 三帧）
• cargo build 零警告
• 有头应用真实启动验证：界面渲染正常，FTDI 设备（/dev/cu.usbserial-A5069RR4）正确枚举
• 人工硬件测试通过：收发、Txt/Hex 切换、大数据发送（2M 波特率下 2560B/100ms 稳定）
  • 测试中发现的 115200 下发送超时已确认为物理带宽超限（25.6 KB/s 需求 > 11.52 KB/s 线路容量），非本重构回归，发送路径未改动

明确不做（后续 Step）

• 读线程死亡仍静默（golden_reader_death_is_silent_today 钉住现状）→ Step 3 生命周期修复
• 前端仍为轮询 → Step 4 事件推送

---

Note

Medium Risk
Touches the hot-path serial RX loop and changes how very large continuous payloads appear as frames, though legacy delimiter/timeout semantics are otherwise preserved and heavily golden-tested.

Overview
RFC #3 Step 2 slims the serial read thread by delegating all framing to FrameSegmenter and centralizing RX handling in one emit_frame path (text recording, display formatting, logs, stats), replacing four copy-pasted blocks.

FrameSegmenter now enforces DEFAULT_MAX_FRAME_BYTES (64 KiB) during feed(): delimiter matches only count inside the first cap-sized window; otherwise the buffer is emitted in cap-sized chunks even without idle timeout. Timeout-mode idle flush is unchanged; raw recording still taps bytes before framing.

Intentional behavior change: delimiter-free streams no longer produce arbitrarily large log frames—they split at 64 KiB (with a pinned edge case when a delimiter straddles the cap). New unit and scripted-port golden tests cover hard cuts and a 150 KiB continuous stream.

^{Reviewed by Cursor Bugbot for commit 39171ee. Bugbot is set up for automated code reviews on this repo. Configure here.}

[cursor]

Bugbot couldn't run - usage limit reached

Bugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit.

A user or team admin can review and increase usage limits in the Cursor dashboard.

(requestId: serverGenReqId_60cc9f10-ca93-4feb-bf6c-3769c92c96e7)