Exercise 2: A Word Wider Than the Available Width Still Gets Placed — Possible Solution
====================================================================

THE TEST
------------------------------
    break_into_lines(['The'], 10)

RESULT
------------------------------
    [['The']]

'The' (24px wide, per the chapter's own 8px/char model) is placed on
its own single line, even though the available width (10px) is less
than a quarter of the word's own width.

WHY THE WORD IS NEVER REJECTED OR DROPPED
------------------------------
Walking through break_into_lines for this single-word input:

    for word in words:                       # just one iteration, word='The'
        w = measure_word(word)                # w = 24
        extra = w if not current_line else (w + SPACE_WIDTH_PX)
                                               # current_line is [] (empty) at this point,
                                               # so `not current_line` is True -> extra = w = 24
        if current_line and current_width + extra > available_width:
            ...                                # NEVER REACHED
        else:
            current_line.append(word)          # THIS branch runs
            current_width += extra

The overflow-check condition is `if current_line and ...` -- an `and`
requiring BOTH current_line to be non-empty AND the width check to
fail. Since current_line starts as an empty list `[]`, which is falsy
in Python, the `current_line and ...` expression short-circuits to
False immediately, without even evaluating the width comparison on the
right-hand side at all. The `else` branch always runs for the very
first word placed into a fresh, empty line, appending it unconditionally.

THE GUARANTEE THIS PRODUCES
------------------------------
A new line only ever gets STARTED (by hitting the `if` branch and
resetting current_line to `[word]`) once a line is already non-empty
AND the next word wouldn't fit. That means the FIRST word placed onto
any given line is never subject to the overflow check at all -- it is
always accepted, regardless of its own width relative to
available_width. A lone word that's wider than the entire available
space still becomes the sole occupant of its own line: the algorithm
has no code path that can produce an empty line, and no code path that
silently discards a word instead of placing it somewhere.

WHY THIS WORKS AS AN ANSWER
------------------------------
This is a deliberate, necessary design choice, not an accidental gap:
real CSS text layout has exactly this same behavior for an unbreakable
run of characters wider than its own container (a long URL with no
spaces, for instance) -- the browser doesn't refuse to render it or
crash; it lets that one line visually overflow its own box. Guarding
the overflow check with `current_line and ...` is precisely what
implements "always accept the first word on a line, no matter what" --
without that guard, an empty current_line's own current_width of 0
plus a wide word's own width would still correctly evaluate as
"doesn't fit," but there would be nothing sensible to do about it
(you can't start ANOTHER new line for a word that was never placed
anywhere), so the guard exists specifically to sidestep that dead end.