bug: reject framing-breaking custom command protocol headers

[codeforester]

Goal

Reject custom command-protocol headers that break LF framing before any payload is serialized or parsed.

Background

CommandCodec intentionally supports a custom protocol_header for legacy wire compatibility, but neither dumps_records() nor loads_records() validates that it is one nonempty framing-safe line. A header containing LF is serialized into multiple lines and can never be read back using the same header. Control characters and an empty header are similarly outside the framing contract.

Reproduction and evidence

Framework reference: 263d893 on main.

payload = codec.dumps_record(
    "demo", {"name": "x"}, protocol_header="BAD\nHEADER"
)
payload.splitlines()[:3]
# ['BAD', 'HEADER', 'record_type=demo']

codec.loads_records(payload, protocol_header="BAD\nHEADER")
# CommandProtocolError: unsupported protocol header; expected BAD\nHEADER

The encoder accepts and emits a payload the decoder cannot round-trip.

Scope

• Define a framing-safe custom-header grammar.
• Validate the header consistently on encode and decode before processing records.
• Raise CommandProtocolError with a bounded, non-control-bearing diagnostic.
• Retain the documented legacy BASE_COMMAND_PROTOCOL_V1 use case.
• Add empty/newline/CR/control and valid-custom-header tests.

Acceptance criteria

• Every accepted custom header round-trips.
• LF, CR, NUL, other framing controls, and empty headers are rejected before output.
• The default and documented legacy headers remain compatible.
• Diagnostics cannot inject additional terminal or protocol lines.

Project fields

• Status: Backlog
• Priority: P2
• Area: Python
• Initiative: v1.0 Readiness
• Size: S

Ownership

• Assignee: @codeforester