Exercise 1: Coalescing Regardless of Free Order — Possible Solution
====================================================================

THE TEST
------------------------------
    mem = PhysicalMemory(300)
    a = mem.alloc_first_fit(100)   # address 0
    b = mem.alloc_first_fit(100)   # address 100
    c = mem.alloc_first_fit(100)   # address 200

    # free out of order: B, then A, then C
    mem.free_coalescing(b, 100)
    mem.free_coalescing(a, 100)
    mem.free_coalescing(c, 100)
    print(mem.free_list)

RESULT
------------------------------
    free list after freeing B, then A, then C (out of physical order): [(0, 300)]

Even though the three blocks were freed in a completely different
order than they were allocated in (B, then A, then C -- not A, B, C),
the free list ends up as a single, fully-merged 300-byte region,
identical to what a sequential free order would have produced.

WHY THE ORDER GENUINELY DOESN'T MATTER
------------------------------
free_coalescing() always does the same two things on every call,
regardless of what's already in the free list: append the newly-freed
block, then re-sort the ENTIRE free list by address before merging.

    self.free_list.append((start, size))
    self.free_list.sort()
    ...merge adjacent entries...

Sorting by address before merging means the merge step never has to
know or care what order blocks were actually freed in -- by the time
merging runs, the free list is always laid out in physical address
order, and "physically adjacent" is simply "next to each other in
this sorted list." Freeing B first leaves the free list as
[(100,100)] -- nothing to merge with yet, since 0-100 and 200-300
are still allocated. Freeing A next makes it [(0,100),(100,100)],
which DOES merge (0-100 and 100-100 are adjacent) into [(0,200)].
Freeing C last makes it [(0,200),(200,100)], which merges again into
the final [(0,300)].

WHY THIS IS THE CORRECT, EXPECTED BEHAVIOR
------------------------------
A real kernel has no control over the order in which running
processes happen to free their own memory -- process B might exit
before process A even though A started first. An allocator whose
correctness depended on blocks being freed in a specific order would
be a genuinely fragile, unrealistic design. Re-sorting by address on
every free() is what makes coalescing order-independent by
construction, not by coincidence.

WHY THIS WORKS AS AN ANSWER
------------------------------
Deliberately freeing in a scrambled, non-sequential order and
confirming the exact same fully-merged result as sequential freeing
would produce rules out the possibility that Finding 3's own
demonstration only happened to work because A and B were freed in
their own natural order.