Exercise 1: PIDs Are Never Reused — Possible Solution
====================================================================

THE TEST
------------------------------
    kernel = Kernel(mem)
    first = kernel.create_process(num_pages=1)
    first.transition(ProcessState.RUNNING)   # must be RUNNING before it can terminate
    kernel.terminate_process_fixed(first.pid)

    second = kernel.create_process(num_pages=1)
    print(first.pid, second.pid)

RESULT
------------------------------
    first process PID: 16, second process PID (after first exited): 17

second.pid is strictly greater than first.pid, and the two are never
equal, even though first's own process has fully exited and its own
memory has already been reclaimed.

WHY PIDS NEVER GET REUSED IN THIS ENGINE
------------------------------
PCB._next_pid is a class-level attribute, shared by every PCB
instance, incremented once per __init__() call and never decremented
or reset anywhere -- not in transition(), not in
terminate_process_fixed(), not anywhere else in the kernel. Once a
PID has been handed out, nothing in this engine's own code path is
even capable of handing it out again; the counter only ever moves
forward.

THE REAL TRADEOFF: NEVER REUSING VS. RECYCLING PIDS
------------------------------
This engine's own choice -- a strictly increasing counter -- is the
simplest possible design, and it comes with one genuine, permanent
correctness guarantee: a PID uniquely and permanently identifies
exactly one process that ever existed, for the life of the kernel.
Nothing else can ever be confused with it.

Many real operating systems instead recycle PIDs once they become
free, typically bounded within some fixed range (Linux's own default
is 32768). The upside is real: PID numbers stay small and bounded
forever, rather than growing without limit as a long-running system
creates millions of short-lived processes over time. The cost is
real too: any code anywhere in the system that stored a PID and
expects to use it LATER (a log entry, a monitoring tool, a signal
sent to "process 4021") now has to be careful that PID 4021 hasn't
since been reused by a completely unrelated, newer process -- a real,
documented source of bugs in systems that don't handle PID reuse
carefully (a "PID wraparound" bug, in real OS terminology).

WHY THIS WORKS AS AN ANSWER
------------------------------
Directly observing that PIDs never repeat, even across a real
terminate-then-create cycle, confirms this engine's own specific
design choice as implemented -- and naming the real tradeoff against
PID recycling (rather than assuming "never reuse" is obviously
correct or obviously wasteful) shows the choice is a genuine
engineering tradeoff, not an oversight.