Exercise 1: A Generous Width Fits Everything on One Line — Possible Solution
====================================================================

THE TEST
------------------------------
    words = "The quick brown fox jumps over the lazy dog".split()
    break_into_lines(words, 400)

RESULT
------------------------------
    [['The', 'quick', 'brown', 'fox', 'jumps', 'over', 'the', 'lazy', 'dog']]

One single line containing all nine words.

WHY EVERYTHING FITS ON ONE LINE
------------------------------
The individual word widths (8px/char) are: The=24, quick=40, brown=40,
fox=24, jumps=40, over=32, the=24, lazy=32, dog=24 -- summing to
24+40+40+24+40+32+24+32+24 = 280. There are 8 gaps between the 9
words, each costing SPACE_WIDTH_PX (8), adding 8*8=64. Total real
rendered width = 280 + 64 = 344.

Since break_into_lines never starts a new line while the running total
(including the space about to be added) stays at or under
available_width, and 344 <= 400, every word gets appended to the same
current_line without ever triggering the `current_line and current_width
+ extra > available_width` overflow condition.

CONFIRMING THE REAL RENDERED WIDTH, NOT JUST TRUSTING THE RESULT
------------------------------
Using the chapter's own real_rendered_width() formula directly on the
single returned line:

    real_rendered_width(line) = sum(word widths) + (len(line)-1) * SPACE_WIDTH_PX
                               = 280 + 8*8 = 280 + 64 = 344

344 <= 400 -- confirmed within budget. This is the same formula the
chapter used to CATCH the naive algorithm's own bug in the first
place; using it again here, on the fixed algorithm's own output,
confirms the fixed result isn't just "one line because there was only
one line" by construction -- it's independently verified to actually
fit, using the same measurement standard the bug was originally caught
with.

WHY THIS WORKS AS AN ANSWER
------------------------------
This is the "no wrapping needed" baseline case -- when the available
width is generous enough that the real rendered width of the ENTIRE
paragraph, spaces included, still comes in under budget, the
line-breaking loop simply never has a reason to start a second line at
all. It's a useful sanity check precisely because it's the simplest
possible outcome: if this case ever failed (say, an off-by-one
comparison that returned two lines unnecessarily even when everything
fit), it would be immediately obvious against a case this clear-cut.