[kkkhs]

What

Fixes #956. A BOM-prefixed line was already delivered through ReadBuffer's recovery path, but readMessage first logged an ERROR with a stack trace and the whole line.

Fix

• A recovered line is logged once at WARN, without a stack trace.
• A dropped line is logged once at ERROR (previously up to two ERRORs).
• Logs carry a 160-char line prefix instead of the whole line.

Test

Added a ReadBuffer regression for BOM-prefixed messages.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[Copilot]

🟢 Approval recommended

The BOM handling change is covered by a regression test, and no unresolved review issues remain.

No open issues 🎉

_{Review effort: Lite}

[devcrocod]

Thanks for the PR!
A BOM prefix line is already delivered now via tryRecover. What #956 actually shows is the error with a stack trace that readMessage logs before recovery even runs.
Rather than adding another parsing rule, could you rework the logging:
WARN without a stack trace when recovery succeeds,
ERROR only when the line is dropped?
And please log a truncated prefix instead of the whole line.

[Copilot]

🟡 Changes recommended

BOM-prefixed valid frames still take the malformed-input recovery path and emit a warning, so the initial deserialization must strip the BOM and regression coverage should verify that behavior.

1 open issue

• Strip BOM before initial message deserialization · New

_{Review effort: Lite}

[Copilot]

🟡 Changes recommended

The BOM-prefixed line is still deserialized before normalization, causing affected frames to fail initially and rely on recovery while emitting warnings; leading BOM characters should be stripped before the first parse attempt.

2 open issues

• Normalize BOM-prefixed lines before deserialization · New
• Strip BOM before initial message deserialization

_{Review effort: Lite}

[devcrocod]

lgtm