Challenge 3: Why Separate Chaining Works, and What Overwriting Would Break — Possible Solution
====================================================================

A hash function, by its very nature, maps a potentially unlimited
number of distinct keys down onto a fixed, finite number of bucket
indices (per the chapter, key % bucket_count). This means COLLISIONS
-- two genuinely different keys hashing to the exact same bucket index
-- are not a rare edge case to be avoided; they are a mathematically
GUARANTEED eventual outcome once the number of keys inserted exceeds
the number of buckets (and can happen even before that, depending on
the specific keys and hash function). Any usable hash table design has
to have some real strategy for handling this, since it isn't optional.

Separate chaining works because each bucket doesn't hold a single
key-value pair directly -- it holds its OWN independent linked list of
however many pairs happen to hash to that index. When a new key hashes
to a bucket that already contains something, the new pair is simply
APPENDED to that bucket's list rather than replacing what's already
there -- both the old and new key-value pairs remain fully present and
independently retrievable (a lookup then has to walk that bucket's
short list comparing actual keys, not just the hash, to find the
specific match).

What would go wrong if a hash table simply OVERWROTE whatever was
already in a bucket: the moment two different keys collide, inserting
the second key's value would silently DESTROY the first key's value --
not because anything explicitly deleted it, but purely as an
unavoidable side effect of both keys mapping to the same storage slot.
Looking up the first key afterward would either return the second
key's value (silently wrong data) or nothing at all, with no error or
warning that data had been lost. Given that collisions are guaranteed
to happen eventually in any hash table with enough entries, an
overwrite-based design would be fundamentally, structurally broken --
not an edge case, but a routine, expected way to silently lose data.

WHY THIS WORKS AS AN ANSWER
------------------------------
This explains WHY collisions are unavoidable (a hash function maps
unlimited keys onto finite buckets) rather than treating them as a rare
fluke, and traces the concrete consequence of an overwrite-based
design (silent data loss, not just an occasional bug) to show why
separate chaining -- preserving every colliding entry rather than
replacing it -- is a structural necessity, not an optional refinement.