Challenge 3: Why push_back Is "Amortized O(1)," Not Simply "O(1)" — Possible Solution
====================================================================

Per the chapter, std::vector stores its elements in CONTIGUOUS memory,
not a linked structure -- meaning all of a vector's elements have to
sit in one unbroken block. When a push_back call would exceed the
vector's currently allocated capacity, a single push_back call is NOT
a cheap, constant-time operation: the vector must allocate an entirely
NEW, larger block of memory, then copy or move EVERY existing element
from the old block into the new one, before finally adding the new
element -- an operation whose cost is proportional to the vector's
CURRENT SIZE (O(n) for that one specific call), not constant.

If push_back were simply O(1), every single call would need to take
roughly the same, small amount of time, with no exceptions -- but the
occasional reallocating call described above genuinely takes longer,
proportional to how many elements already exist. Calling it plain
"O(1)" would be inaccurate, since SOME individual calls are
demonstrably not constant-time.

"Amortized O(1)" is the precise, honest description instead: it means
that although individual calls vary in cost (most are truly O(1),
simply appending into already-allocated spare capacity; occasional
ones are O(n), due to reallocation), the TOTAL cost of performing N
push_back calls in a row, divided by N, still averages out to a
constant per call -- because vectors typically grow their capacity
geometrically (e.g. doubling) rather than by one element at a time,
so the expensive reallocations become exponentially rarer as the
vector grows, and the total copying work across all reallocations up
to size N sums to no more than a constant multiple of N.

WHY THIS WORKS AS AN ANSWER
------------------------------
This explains precisely what happens during the "occasional more
expensive call" (a full reallocation and copy of every existing
element, tied to contiguous memory), and explains why "amortized"
specifically (rather than plain O(1)) is the accurate description --
because the AVERAGE cost per call stays constant across many calls,
even though individual calls genuinely vary.