Exercise 2: Priority Scheduling Works Correctly With Negative Priorities — Possible Solution
====================================================================

THE TEST
------------------------------
    neg_runner.transition(ProcessState.RUNNING)   # priority -1
    scheduler.add(zero_proc, priority=0)
    scheduler.add(very_neg, priority=-10)
    # run 30 turns

RESULT
------------------------------
    priorities: neg_runner=-1, zero_proc=0, very_neg=-10
    turns over 31: {neg_runner: 16, zero_proc: 15, very_neg: 0}

very_neg (-10) is starved completely, exactly like Finding 2's own
low-priority process -- while neg_runner (-1) and zero_proc (0)
alternate normally between themselves, the same alternating pattern
Finding 1 already demonstrated for positive priorities.

WHY NEGATIVE PRIORITIES WORK WITHOUT ANY SPECIAL-CASING
------------------------------
pick_next()'s entire comparison is a single line:

    if self.ready_queue[i][1] > self.ready_queue[best_idx][1]:

Python's `>` operator works identically on negative integers, zero,
and positive integers -- -1 > -10 is True in exactly the same sense
that 10 > 1 is True. Nothing in PriorityScheduler ever checks whether
a priority is >= 0, casts it to an unsigned type, or does anything
else that would silently break for negative values. The algorithm was
never actually built around "priority is a small positive number" --
it only ever needed "priority is a value orderable with >," and
Python's own integers satisfy that for any sign.

WHY THIS IS WORTH CONFIRMING DIRECTLY, NOT JUST ASSUMING
------------------------------
It would have been easy to accidentally introduce an assumption that
breaks this -- for example, initializing a "best priority found so
far" variable to 0 instead of to the first real entry's own value
would silently misbehave the moment every candidate priority was
negative (nothing would ever compare as "greater than 0"). The actual
implementation avoids this specific trap by seeding best_idx from a
real entry (index 0) rather than from a hardcoded numeric baseline --
but that's exactly the kind of assumption that's only obvious once
it's been checked, not something to take on faith.

WHY THIS WORKS AS AN ANSWER
------------------------------
Deliberately choosing a mix of negative and zero priorities, rather
than only shifting everything down by the same constant, tests that
RELATIVE ordering is genuinely all that matters -- confirming the
scheduler doesn't secretly depend on priorities starting from any
particular reference point (0, 1, or anything else).