Exercise 2: What Expand-Contract Is For — Possible Solution
====================================================================

WHAT THE PATTERN ACTUALLY IS
------------------------------
Per this chapter, "expand first (add the new column/field, deploy code
that can handle both the old and new shapes at once), let that settle
completely, then contract (remove the old field in a later, separate
release)." Two clearly separated phases, deployed independently rather
than simultaneously.

WHAT IT'S DESIGNED TO PREVENT
------------------------------
Per this chapter, "the whole point is avoiding any single moment where
a schema change and a code deploy have to land in perfect lockstep."
Without this pattern, a migration and its dependent code deploy would
need to complete at the exact same instant for the system to remain
consistent - which is genuinely difficult to guarantee in practice,
since migrations and deploys are often separate operations that can
each take variable amounts of time.

THE SPECIFIC FAILURE MODE IT PREVENTS
------------------------------
Per this chapter, "a sudden burst of 'field not found' or 'column does
not exist' errors immediately following a deploy is the classic
symptom of that discipline having been skipped." Without expand-
contract, code could be deployed expecting a schema change that hasn't
actually finished (or even started) on the database yet - or,
symmetrically, old code could still be running against a schema that's
already been altered out from under it. Both produce exactly this
class of "field/column doesn't exist" error.

WHY THIS WORKS AS AN ANSWER
------------------------------
It describes the two-phase pattern accurately, explains the underlying
timing problem it solves (lockstep dependency between deploy and
migration), and names the specific error symptom the chapter
identifies as evidence the pattern wasn't followed.