Exercise 1: Two Processes Tied at the Exact Same Priority — Possible Solution
====================================================================

THE TEST
------------------------------
    runner.transition(ProcessState.RUNNING)
    scheduler.add(tied_a, priority=5)
    scheduler.add(tied_b, priority=5)   # identical priority to tied_a

    # runner itself given a deliberately LOW priority (1) so it never wins again
    for _ in range(3):
        current, pri = run_priority(cpu, scheduler, current, pri)
        order.append(current.pid)

RESULT
------------------------------
    order processes were picked in: [tied_a.pid, tied_b.pid, tied_a.pid]

tied_a -- the one added to the queue FIRST -- is picked first.

WHY tied_a WINS THE TIE
------------------------------
pick_next()'s own scan is:

    best_idx = 0
    for i in range(1, len(self.ready_queue)):
        if self.ready_queue[i][1] > self.ready_queue[best_idx][1]:
            best_idx = i
    return self.ready_queue.pop(best_idx)

This is a STRICT greater-than comparison. best_idx starts at index 0
(tied_a, since it was added first) and only ever gets REPLACED if a
later entry is STRICTLY greater. tied_b's own priority (5) is equal
to, not greater than, tied_a's own priority (5) -- so the condition
is False, and best_idx never moves off tied_a. tied_a wins by default,
simply because it was the first entry the scan encountered that
nothing else ever managed to beat.

WHAT WOULD CHANGE WITH A DIFFERENT COMPARISON
------------------------------
If the comparison were `>=` instead of `>`, every tied entry
encountered LATER in the scan would overwrite best_idx, since a value
equal to the current best would count as "good enough to replace it."
With exactly two tied entries, that would flip the winner: tied_b
(scanned at index 1, replacing tied_a's own index-0 default) would win
instead. The tiebreak direction here isn't a deliberate design choice
written down anywhere -- it's a direct, mechanical consequence of
which single comparison operator (`>` vs `>=`) was used in the loop.

WHY THIS WORKS AS AN ANSWER
------------------------------
Running the tied scenario for multiple turns (not just once) confirms
the tiebreak is CONSISTENT, not a one-off coincidence of iteration
order -- tied_a keeps winning every time it's the earliest tied entry
present, which is exactly what "scan order plus a strict '>' " predicts
mechanically, not just plausibly.