Challenge 1: Why Tree Needs Box — Possible Solution
====================================================================

enum Tree { Leaf(i32), Node(Box<Tree>, Box<Tree>) } COMPILES because
each Box<Tree> has a FIXED, KNOWN SIZE — a Box is always just a single
pointer (a memory address), regardless of what type it points to. The
compiler can compute Tree's total size as: the size of the largest
variant, which here is Node's two pointer-sized Box fields — a
perfectly ordinary, finite number of bytes, known at compile time.

enum Tree { Leaf(i32), Node(Tree, Tree) } (without Box) does NOT
compile, for exactly the reason this chapter's List example
illustrated: to compute Tree's size, the compiler would need to know
the size of a Node variant, which contains two Tree values directly
(not references or pointers to them) — but computing THAT size
requires knowing the size of Tree again, which requires knowing the
size of Tree again, and so on, infinitely. There's no base case that
ever bottoms out at a concrete number of bytes — the type's size is
genuinely undefined/infinite from the compiler's perspective, which is
precisely the same infinite-recursion problem this chapter's Cons(i32,
List) vs Cons(i32, Box<List>) example demonstrated. Box breaks this
exact cycle by replacing "a Tree directly" with "a fixed-size pointer
to a Tree stored elsewhere (on the heap)," giving the compiler a
concrete size to work with regardless of how deeply nested the actual
tree structure ends up being at runtime.