Exercise 1: Recovery Over an Already-Clean WAL — Possible Solution
====================================================================

THE TEST
------------------------------
    heap = HeapFile(heap_path)
    wal = WAL(wal_path)
    pn = heap.allocate_page()
    page = Page(); page.add_record(b'CLEAN-ROW')
    wal.append(pn, bytes(page.data))
    heap.write_page(pn, page)                       # fully applied
    heap.file.flush(); os.fsync(heap.file.fileno())  # confirmed durable
    open(wal_path, 'wb').close()                     # cleanly truncated -- no crash

    n = recover(heap, wal_path)
    after = heap.read_page(pn)

RESULT
------------------------------
    records applied on an already-clean WAL: 0
    page unchanged and still correct: True

recover() applies zero records, and the page's own bytes are
identical before and after the call.

WHY THIS IS THE CORRECT, EXPECTED OUTCOME
------------------------------
recover()'s own first step is read_all_records(wal_path) -- against
a WAL file that has just been truncated to zero bytes, this
correctly returns an empty list, since there is nothing there to
read. The rest of the function is just a for loop over that list;
an empty list means the loop body never executes even once, and the
function returns having done nothing at all.

WHY THIS MATTERS AS A CORRECTNESS PROPERTY, NOT JUST A CONVENIENCE
------------------------------
This is the same "recovery has no idea whether a crash actually
happened" property Finding 2 already established, taken to its
natural extreme: recover() doesn't distinguish between "there was no
crash, and everything is already fine" and "there WAS a crash, and
some records genuinely need reapplying" -- it treats both cases
identically, by reading whatever the log can currently prove and
replaying exactly that. When nothing needs replaying, the log
correctly proves nothing, and recover() correctly does nothing. A
real database can safely call recover() on every single startup,
crash or no crash, without needing a separate flag or check for
"was there actually a crash last time" -- the log's own contents
answer that question implicitly.

WHY THIS WORKS AS AN ANSWER
------------------------------
Confirming recover() is a genuine no-op on a clean WAL -- not just
"probably harmless," but observably applying zero records and
leaving the data untouched -- rules out the possibility that
recovery does something unnecessary or wasteful on the ordinary,
uneventful startup path, which is by far the most common case in
practice.