Exercise 3: Aborting a Process Not in the Cycle Doesn't Fix Anything — Possible Solution
====================================================================

THE TEST
------------------------------
    # t1/t2 deadlock exactly like Finding 1; bystander never touches A or B
    programs[bystander.pid] = []

    # confirm the real deadlock first
    cycle = find_cycle(build_wait_for_graph(dk))   # -> [t1, t2, t1]

    # mistakenly "recover" by aborting the bystander instead
    released = abort_and_release_all(dk, bystander.pid)

RESULT
------------------------------
    deadlock confirmed between t1 and t2: cycle = [11, 12, 11]
    mistakenly aborting the BYSTANDER (not in the cycle) released: []
    after the wrong abort and 500 more real steps, t1/t2 remaining ops: {11: 3, 12: 3}

released is an empty list -- the bystander held nothing, so there was
nothing to release. t1 and t2's own remaining op counts are completely
unchanged (3 and 3, exactly as before the "recovery" attempt) after
500 more real steps.

WHY ABORTING THE BYSTANDER CHANGES NOTHING
------------------------------
abort_and_release_all() only does one thing: it iterates over every
resource, and for each one currently held by the given PID, releases
it. The bystander process never issued a single ACQUIRE in this
scenario, so res.held_by is never equal to the bystander's own PID for
either resource A or B -- the loop finds nothing to release. The
deadlock's own root cause -- t1 holding A while wanting B, and t2
holding B while wanting A -- is completely untouched by anything that
happens to a process that was never part of that circular
relationship in the first place.

WHY THIS MATTERS FOR REAL RECOVERY
------------------------------
This demonstrates precisely why Finding 2's own wait-for-graph
detection isn't an optional nicety before recovery -- it's the ONLY
reliable way to know which process's abort will actually help.
Aborting an arbitrary or convenient-looking process (the newest one,
the one using the most memory, the one that happens to be running
right now) without first confirming it's genuinely a member of the
detected cycle can waste real work (terminating a perfectly innocent
process) while leaving the actual deadlock completely intact,
silently, with no error or feedback indicating the "fix" didn't work.

WHY THIS WORKS AS AN ANSWER
------------------------------
Deliberately choosing the WRONG process to abort, rather than
Finding 4's own correct choice, and measuring that the deadlock
persists unchanged afterward, converts an assumption ("of course you
need to abort the right one") into a concrete, verified demonstration
of exactly what "wrong" looks like -- zero resources released, zero
progress made, the exact same permanent stall as before the attempted
recovery.