Challenge 3: Why Rust's Ownership Model Makes a Double-Free Structurally Impossible — Possible Solution
====================================================================

A double-free happens when the same piece of heap memory is freed
twice -- in C, per the chapter, this is undefined behavior, because
nothing stops a program from calling free() on a pointer whose memory
was already released by an earlier free() call on that same pointer
(or a copy of it).

Rust's ownership model prevents this not by detecting and rejecting a
double-free at the moment it would happen, but by making the SITUATION
that would lead to one impossible to construct in the first place.
Every value in Rust has exactly ONE owner at any given time (rust1-3's
own core rule). When a value is assigned to a new variable or passed
elsewhere, ownership MOVES -- the original variable is no longer
considered valid, and the compiler tracks this at compile time,
rejecting any subsequent attempt to use the original variable at all.
Since Rust automatically calls the equivalent of free (technically,
runs the value's Drop implementation) exactly once, at the moment its
single current owner goes out of scope, and only ONE variable can ever
be "the owner" responsible for that at any given moment, there is
structurally no way for two separate owners to each independently
trigger a free on the same underlying memory -- there is only ever one
owner, and thus only ever one point where the automatic free happens.

This is meaningfully different from C's situation, where a pointer can
be freely copied (multiple variables can hold the SAME address, with
nothing distinguishing which one is "responsible" for freeing it), and
each copy is a plain value the programmer can call free() on
independently, with no tracking of whether another copy already did
so. Rust's compiler, by contrast, refuses to compile code that would
even ATTEMPT to use a moved-from (previously owning, now invalidated)
variable -- so the second "free" call a double-free would require
literally has no valid variable left to be written against.

WHY THIS WORKS AS AN ANSWER
------------------------------
This explains the actual mechanism (single ownership plus compile-time
tracking of moved-from variables) that makes a double-free
UNCONSTRUCTABLE in Rust, rather than merely claiming Rust "checks for
it" -- the key insight is that Rust prevents the SITUATION of two
owners existing at all, not that it detects and blocks the second free
call at runtime.