bug: [P1] 非法长度头后的完整帧被挂起，必须等额外字节到达才交付 #64

评审基线：StreamFrame 2.6.0，提交 4b892d9eaa11cf003b5d10793e735b0604bc17ed（2026-09-08 仓库评审）。

问题与影响

P1，已独立复现。 同一批输入含“坏长度头 + 合法完整帧”时，坏头被丢弃，但后续完整帧不立即交付。请求—响应协议中，对端等待应答、不再发字节，可导致双方一直等待。

位置：src/StreamFrame/Framing/LengthPrefixFramer.cs:77；
src/StreamFrame/Connection/FrameDecoder.cs:95；
src/StreamFrame/Connection/FrameDecoder.cs:144。

原因链：非法长度分支消费四字节后返回 false → Decoder 的 while 循环结束 → AdvanceTo(buffer.Start, buffer.End) 将剩余完整帧标记为已检查 → 等待更多网络输入。这里混淆了“已有消费进展，可继续解析”和“必须等更多字节”。

最小报文与实测

Windows、.NET 8.0.30，默认 LengthPrefixFramer，普通 byte[]/string Codec：

FF FF FF FF  00 00 00 03  41 41 41
^^^^^^^^^^  ^^^^^^^^^^^  ^^^^^^^^
非法长度头   合法长度=3    payload=AAA

1. 本地 TcpClient 连接被动 StreamConnection，启动 GetMessages 消费。
2. 一次 WriteAsync 写入以上完整报文。
3. 等 FrameError 确认坏头已被处理，500ms 后消息任务仍未完成。
4. 再发送单字节 00，之前的 AAA 立即交付。

实测输出：

message completed after invalid header + valid frame = False
after extra byte delivered=3

建议与验收

• 明确 Framer false 返回值与缓冲推进契约；发生消费进展时能继续处理现有缓冲，且无进展时不会忙循环。
• 坏头 + 合法完整帧在没有后续写入的情况下立即交付。
• 覆盖连续多个坏头、合法半帧、粘包、EOF，以及自定义 Framer false 但推进缓冲的情形。
• 开启 IncompleteFrameTimeout 时，不把已经完整缓冲的消息误当半帧超时。
• FrameError 丢弃字节、SessionId 和快照元数据保持正确。
• 保留当前明确的重同步策略，若要改变非法长度为断连策略需单独说明兼容影响。

实施按 AGENTS.md：从最新 main 建分支、同步 CHANGELOG Unreleased、通过 Release build/test、走 PR；本 Issue 仅登记工作，不代表已实施修复。