Exercise 1: Length-Prefixing Fixes a Single Writer, But Not Multiple — Possible Solution
====================================================================

THE TEST -- PART A: ONE WRITER
------------------------------
    encoded_a = encode_length_prefixed(MSG_A)   # b'\x02HI'
    encoded_b = encode_length_prefixed(MSG_B)   # b'\x03BYE'
    # ONE writer sends both, back to back
    programs[solo_writer.pid] = [('write_byte', b) for b in (encoded_a + encoded_b)]

RESULT -- PART A
------------------------------
    ONE writer sends both b'HI' and b'BYE', length-prefixed, back to back
    decoded using the length prefixes: [b'HI', b'BYE']

Decoding works perfectly -- both original whole messages recovered
exactly.

THE TEST -- PART B: TWO WRITERS
------------------------------
    # writer A sends encoded_a's bytes, writer B sends encoded_b's bytes,
    # both racing for the same pipe under real QUANTUM=1 preemption

RESULT -- PART B
------------------------------
    raw bytes received: b'\x02\x03HBIYE'
    decoded using the length prefixes: [b'\x03H', b'IYE']

Decoding produces garbage -- neither original message is recovered.

WHY PART A WORKS
------------------------------
With a single writer, every byte it writes -- length byte, then payload
bytes -- goes onto the pipe in the exact order the writer's own program
specifies, with nothing else able to write in between (there is no
second writer at all). The reader's own decode loop can trust that the
first byte it reads is genuinely a length, because nothing else could
possibly have been interleaved before it.

WHY PART B FAILS
------------------------------
With two independent writers, EVERY byte on the pipe -- including each
writer's own length byte -- is subject to the exact same scheduler-
driven interleaving Finding 2 already demonstrated for plain message
bytes. In the actual run, writer A's length byte (0x02) and writer B's
length byte (0x03) both land on the pipe FIRST, back to back, before
either writer's own payload bytes arrive. The reader's decode loop
reads 0x02 as "the next message is 2 bytes," but those next 2 bytes
are actually B's own length byte (0x03) and A's first payload byte
('H') -- completely unrelated to A's real message. There is nothing
special about a length byte that exempts it from interleaving; it's
just another byte on the pipe, sharing exactly the same fate as every
byte in Finding 2's own plain example.

WHY THIS MATTERS
------------------------------
This is a genuinely common real-world mistake: length-prefixing is a
correct and widely-used technique, but it silently assumes ONE writer
at a time actually gets to complete its own framed write before
anything else touches the same pipe. In a real system, that usually
means either restricting a pipe to a single writer, or wrapping each
writer's own complete framed write in a mutex so it becomes one
uninterrupted burst -- which, once done correctly, effectively
reinvents Finding 3's own MessageQueue by hand, one mutex-protected
send at a time.

WHY THIS WORKS AS AN ANSWER
------------------------------
Testing the exact same length-prefixing technique in both the
single-writer case (where it's expected to work) and the multi-writer
case (where Finding 2's own root problem still applies) isolates
EXACTLY what length-prefixing does and doesn't fix -- it solves
"where does one writer's own message end," not "how do multiple
writers avoid interleaving with each other."