Exercise 1: An Unrelated Third Process Is Completely Unaffected — Possible Solution
====================================================================

THE TEST
------------------------------
    # a and b share ONE physical frame at vaddr 0 (the racing pair)
    # bystander has its OWN separate, unshared page
    bystander = kernel.create_process(num_pages=1)
    bystander_paddr = bystander.page_table.translate(0)
    mem.data[bystander_paddr] = 77

    # run the a/b race for 20 real increments each, QUANTUM=1

RESULT
------------------------------
    shared counter after the race (lost updates expected): 10
    bystander process's own private byte, untouched the whole time: 77

The shared counter shows real, measured lost updates (10, well below
the 20 two processes should have achieved together) -- but the
bystander's own value is exactly 77, completely unchanged from what
it was set to before the race ever started.

WHY THE BYSTANDER IS COMPLETELY SAFE
------------------------------
execute_step() only ever touches mem.data[shared_paddr] -- the one
physical address explicitly passed into it. bystander's own physical
frame is a completely different address, allocated separately by
mem.alloc_frame() and never mapped into a's or b's own page table at
any point. There is no code path in this chapter's own race by which
a's or b's own LOAD/INC/STORE sequence could ever read or write
bystander's own frame -- the two are simply operating on entirely
different bytes in the same PhysicalMemoryFramed array.

WHY THIS DISTINCTION MATTERS
------------------------------
It would be easy to misdiagnose this bug as "the kernel corrupts
memory under heavy scheduling" -- a vague, alarming, and wrong
conclusion. The real, precise cause is much narrower: a race condition
requires genuinely SHARED, mutable state accessed through an
unprotected read-modify-write sequence. A process with no shared state
at all -- even one running concurrently with two other processes that
ARE racing -- has nothing to race over, and is provably safe by
construction, not by luck.

WHY THIS WORKS AS AN ANSWER
------------------------------
Deliberately including a process with private-only memory alongside
the racing pair, rather than testing the racing pair in isolation,
confirms the bug is scoped exactly where the chapter claims it is
(shared physical frames) and nowhere else -- a claim that's easy to
state but only genuinely verified by trying to find a counterexample
and failing to.