Rewrite the two game tutorials as instructions rather than commentary

Chapters 17 and 18 read as a code review of a finished listing: they explained
why each decision had been made, walked through the project's own history, and
led with what had once been broken. A reader who wanted to build the game got
the reasoning and had to reconstruct the program.

Both are now step-by-step. Each opens with a picture of the finished game and a
bullet list of the steps, each bullet is a section, and each section states its
goal, shows the code, and says how to check it. Chapter 17 is sixteen steps and
Chapter 18 is thirteen, and the last of each is the assembly: the order of the
file, the full declaration block, and the routines the earlier steps referred to.
Project history is gone -- it belongs in Chapter 14 and in git -- and where a
listing has to do something awkward, the tutorial shows how first and names the
`TODO.md` item that will make it unnecessary second.

**Three defects had no entry anywhere**, which the rewrite found by trying to
state each rule as a rule. §6 item 35: `a - b + c` computes `a - (b + c)`,
because `subtraction()` sits above `addition()` as its own precedence level and
the inner loop eats the `+`. Item 36: only one unparenthesised `AND` or `OR` is
matched, which is item 12's `if`-where-`while` on the one operator pair item 12
did not reach. Item 37: a `GOTO` out of a `FOR` or a `DO` leaks the loop's scope,
so a main loop written that way stops on the thirty-second lost life -- which is
why both games are built out of `LABEL` and `GOTO`, and it is a workaround rather
than a preference. Chapter 3 gains the identifier rule the third trial ran into:
there is no underscore in a name, and the error says `UNKNOWN TOKEN _`.

**`tools/screenshot.c` learned to draw the text layer**, behind a new `text=1`
fence attribute, because Chapter 17's game is characters in the grid and a figure
without that layer is two sprites on black. It opens the bundled font at the size
the standalone frontend uses, so a figure's cell size is the reader's cell size,
and it uses the akgl sink alone rather than a tee so the program's output lands in
the picture instead of on the stdout the caller reads to decide a figure failed.
Both new figures -- `breakout-game.png` and `breakout-game-artwork.png` -- are
generated from listings in the chapters like every other one.

Verified by handing each chapter, alone, to an agent on a much smaller model and
telling it to build the game from the tutorial text with the `examples/` tree off
limits. The first pass scored 3.5 and 3 out of 10 and named what was missing:
routines referred to but never shown, the third level layout, the sprite `DATA`,
the font table, edits to earlier routines that were never marked as edits. Those
are now in. The second pass built a 658-line Chapter 17 game that plays itself
for ninety seconds with the score at 1890 and no error line, and the third built
a 1053-line Chapter 18 game with 61 labels, no invented routines, no gaps found,
and forty seconds clean. 9/10 and 8/10.

One real bug in the new prose, caught in review: Chapter 18's `HITBAR` did not
set the `HIT#` that `BALLPADDLE` reads to decide whether the paddle already
caught the ball. Both suites green in both configurations, `docs_examples` and
`docs_screenshots --check` pass.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EwxGB6TdoVvZ11KQQME9cL

TODO.md

@@ -2100,6 +2100,120 @@ in either corpus runs for minutes, which is why the first of these had never bee
     `AKBASIC_ERR_BOUNDS` from the pool is documented as "bounded and diagnosable, which is the
     point" (`include/akbasic/value.h:34`). With a `TRAP` armed it is currently neither.
 
+### Found while rewriting the game tutorials
+
+Chapters 17 and 18 were rewritten to teach a beginner rather than to explain a finished
+listing, which meant writing every rule down as a rule instead of as a comment beside the
+code that dodges it. Three of them turned out to have no entry anywhere. The first two are
+the same shape as item 12 above — a parser function that consumes one operator where it
+should loop — and the third is why both games are built out of `LABEL` and `GOTO`.
+
+35. **An expression mixing `-` and `+` at the same level is evaluated right to left.**
+    `a - b + c` computes `a - (b + c)`. A C128, and every BASIC this descends from, folds a
+    run of same-precedence additive operators left to right.
+
+    ```basic
+    PRINT 10 - 3 + 2
+    PRINT 1 - 2 - 3
+    ```
+
+    ```output
+    5
+    -4
+    ```
+
+    The second line is right and the first is not; 9 is the answer. **Nothing fails** — this
+    is item 4's failure mode over again, a program that quietly computes something else — and
+    the two tutorials work around it by parenthesising every mixed `+` and `-` as a rule
+    rather than where it happens to matter.
+
+    **The cause is the grammar's shape, not a missing loop.** `subtraction()`
+    (`src/parser.c:425`) sits *above* `addition()` (`:447`) as its own precedence level, and
+    both loop correctly — but `subtraction()`'s right operand is parsed by `addition()`, which
+    then consumes the `+` that should have been the *next* term of the subtraction. `1 - 2 - 3`
+    is right because the outer loop sees both minuses; `10 - 3 + 2` is wrong because the inner
+    one eats the plus first.
+
+    The fix is one additive level rather than two: a single function matching `PLUS` and
+    `MINUS` in one `while`, building left-associatively, with `multiplication()` beneath it.
+    That is what item 12 left half-done — it made each of the two levels fold left without
+    noticing that there should only have been one. Touches `src/parser.c` and wants cases in
+    `tests/parser_expressions.c` beside item 12's, asserting `10 - 3 + 2` is 9 and
+    `10 + 3 - 2` is 11 (which already passes, and is the asymmetry that gives it away).
+
+36. **Only one unparenthesised `AND` or `OR` is matched per expression.** A second one is left
+    in the token stream, and in the place a program actually writes them — a condition — the
+    `THEN` check then finds the wrong token and the line is refused:
+
+    ```basic
+    X# = 1
+    Y# = 2
+    IF X# = 1 AND Y# = 2 THEN PRINT "TWO IS FINE"
+    IF X# = 1 AND Y# = 2 AND X# = 1 THEN PRINT "THREE IS NOT"
+    ```
+
+    ```output
+    TWO IS FINE
+    ? 4 : PARSE ERROR Incomplete IF statement
+    ```
+
+    Parenthesising is the workaround and it works — `IF (A AND B) AND C THEN` parses — which
+    is what the tutorials tell a reader to do. It is a refusal rather than a wrong answer, so
+    it costs a puzzled minute rather than an evening; item 42 in §5 fixed the case of *one*
+    `AND` and stopped there.
+
+    `logicalandor()` (`src/parser.c:329`) is `if ( akbasic_parser_match(obj, OPS, 2) )` at `:339`
+    where `subtraction()` at `:425` is `while`. **This is item 12's defect exactly**, on the
+    one operator pair item 12 did not reach, and the reference has the same shape at
+    `basicparser.go`. The fix is the same fix: `while`, folding left, reassigning `left` from
+    the leaf built on the previous pass. `tests/parser_expressions.c` for the expression form
+    and `tests/parser_commands.c` for the `IF` that made it visible.
+
+    Worth doing together with item 35: they are one afternoon, one file, and between them they
+    are the two rules a tutorial currently has to spend a paragraph on.
+
+37. **A `GOTO` that leaves a `FOR` or a `DO` leaks the loop's scope**, so a program that uses
+    the pattern as its main loop stops after the thirty-second time round:
+
+    ```basic
+    N# = 0
+    LABEL TOP
+    DO
+      N# = N# + 1
+      IF N# < 100 THEN GOTO TOP
+    LOOP UNTIL N# > 99
+    PRINT "SURVIVED " + N#
+    ```
+
+    ```output
+    ? 3 : PARSE ERROR Environment pool exhausted at line 3 (32 in use)
+    ```
+
+    Thirty-two is `AKBASIC_MAX_ENVIRONMENTS` (`include/akbasic/types.h:31`), and the branch
+    that reports is the `DO` being entered for the thirty-third time rather than the `GOTO`
+    that did the damage — the same misattribution item 2 had. The `FOR` form behaves
+    identically.
+
+    **This is a real pattern rather than a contrivance.** A game's main loop is a loop the
+    program leaves from the middle of: losing a life, clearing a level and quitting are all
+    "stop what you are doing and go somewhere else". Both Breakout listings in `examples/`
+    are built out of `LABEL`/`GOTO` for exactly this reason, which is the shape a reader of
+    chapters 17 and 18 is now told to copy, and it is a workaround rather than a preference —
+    a `DO ... LOOP` around the frame would be the natural way to write either one.
+
+    The mechanism is the one item 2 documents from the other end: a loop's environment is
+    pushed when the line is parsed and popped by its `NEXT` or `LOOP`, and nothing else pops
+    it. `GOTO` sets the next line and returns (`akbasic_cmd_goto()`, `src/runtime_commands.c`);
+    it has no idea it has just left a scope.
+
+    A fix has to know which scopes the branch target is *outside* of, which the environment
+    stack can answer if a loop's environment records the source line that pushed it: on a
+    `GOTO`, pop every loop scope whose line is not on the path to the target. That is more
+    machinery than items 35 and 36 want between them, and it is worth pricing against simply
+    documenting it — chapters 13 and 17 both now say "loop with `GOTO`, never jump out of a
+    `DO`", which is a rule a reader can follow. Wants `tests/for_next.c` either way, because
+    the reduction above is four lines and currently nothing asserts it in either direction.
+
 ## 7. Filing gaps against `libakgl`
 
 When phase 7 or phase 8 needs something `libakgl` does not have, **stop and file it** in