Exercise 2: A Record That Can Never Fit, Rejected Cleanly — Possible Solution
====================================================================

THE TEST
------------------------------
    p2 = Page()                  # PAGE_SIZE = 64
    big_record = b'X' * 100      # 100 bytes -- bigger than the whole page

    p2.add_record(big_record)

RESULT
------------------------------
    ValueError: page full

A clean, real exception -- no silent truncation, no partial write, no
corrupted page state.

WHY THIS IS REJECTED
------------------------------
add_record's own check is:

    new_free_space_end = self.free_space_end - record_len
    slot_dir_end = HEADER_SIZE + (self.num_slots + 1) * SLOT_SIZE
    if new_free_space_end < slot_dir_end:
        raise ValueError("page full")

With free_space_end starting at 64 and record_len = 100,
new_free_space_end = 64 - 100 = -36 -- a NEGATIVE number. slot_dir_end,
on a fresh page (num_slots=0), is 4 + 1*8 = 12. Since -36 < 12, the
check correctly raises immediately -- the exception fires before
`self.data[new_free_space_end:...]` is ever reached, so nothing is
written to the page's own bytearray at all.

WHY THIS NEVER REACHES THE "OFF BY ONE SLOT" BOUNDARY THE CHAPTER'S
OWN BUG WAS ABOUT
------------------------------
The chapter's own bug specifically involved a record that was CLOSE
to fitting -- close enough that the naive check's own missing "+1 slot"
adjustment was the exact difference between correctly rejecting it and
incorrectly accepting it into space that then got corrupted. Here, the
100-byte record doesn't just miss fitting by a few bytes -- it exceeds
the ENTIRE page size before the slot directory is even considered at
all (new_free_space_end is already negative). The gap between "this
clearly, drastically doesn't fit" and "this fits, but only if we also
remember the +1" is enormous: a record this oversized would be
correctly rejected by even the NAIVE, buggy version too, since
new_free_space_end being negative already fails any reasonable version
of the check, off-by-one slot-size error or not.

WHY THIS WORKS AS AN ANSWER
------------------------------
This distinguishes two genuinely different kinds of "doesn't fit":
a record that's wildly, obviously too big (this exercise) is a safe,
easy case that any reasonable capacity check gets right; the chapter's
own real bug only showed up in the much narrower, more dangerous
region right at the boundary, where the record's own data would have
fit, but the bookkeeping needed to describe it wouldn't. Testing both
kinds separately confirms the fix doesn't just handle the easy,
obvious overflow case -- it specifically handles the narrow, easy-to-
miss boundary case too.