Accept GRAPHIC CLR and a negative DATA item

Two parse handlers refusing something the documentation promises. Landing
together because they are the same defect twice -- a verb's own argument shape
falling through to a general path that cannot see it -- in one file, found by
one program, and verified in one pass.

**`GRAPHIC CLR`** is given as `GRAPHIC mode | CLR` in both docs/06-graphics.md
and docs/11-verb-reference.md, and was refused: `CLR` is a verb of its own, so
the generic arglist path scanned it as a command token and the expression parser
answered "Expected expression or literal". `akbasic_parse_graphic()` takes it as
this verb's keyword argument and emits mode 5 -- which `akbasic_cmd_graphic()`
already treats as "drop the saved shapes and go back to text", so both spellings
are one statement and the exec handler is untouched. The documentation was right
all along; nothing in it changes.

**`DATA -5`** was refused by `akbasic_parse_data()`, and only there: `READ` scans
the source text directly (src/data.c) and always returned the -5 intact. So the
value was right and *reaching* the statement raised -- which, since section 4
settled that `DATA` at run time is a no-op, is what a program does with every
`DATA` line it walks past. A table of coordinates or velocities is full of
negative numbers, which is how a game found it.

The fix accepts a unary minus over a numeric literal and nothing else: `DATA -A#`
is still a mistake worth naming, and `akbasic_leaf_is_literal()` keeps meaning
what it says because other callers rely on it.

tests/read_data.c covers both mechanisms -- reading a negative item and reaching
the line after it -- with a mixed-sign table and a negative float, since the two
were never the same code path.

TODO.md section 9 items 7 and 8, struck.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

TODO.md

@@ -2751,7 +2751,13 @@ reduced against `build/basic`, the stdio build, unless it says otherwise.
    is not obvious from the failure — every brick simply comes out the colour of the last one
    captured. `tests/graphics_verbs.c` is where the regression goes.
 
-7. **`GRAPHIC CLR` is documented and refused.** `docs/06-graphics.md:65` and
+7. ~~**`GRAPHIC CLR` is documented and refused.**~~ **Done** -- `akbasic_parse_graphic()`
+   (`src/parser_commands.c`) takes `CLR` as this verb's keyword argument and emits mode 5,
+   which `akbasic_cmd_graphic()` already treats as exactly this, so both spellings are one
+   statement and the exec handler is unchanged. The documentation was right and the parser
+   was not; `tests/parser_commands.c` now pins the form the two chapters give.
+
+   The original report: `docs/06-graphics.md:65` and
    `docs/11-verb-reference.md:54` both give the form as `GRAPHIC mode | CLR`.
 
    ```basic
@@ -2770,7 +2776,14 @@ reduced against `build/basic`, the stdio build, unless it says otherwise.
    Worth noting because `docs_examples` cannot catch it: every fenced `GRAPHIC CLR` in the
    documentation is prose, not a tagged runnable block.
 
-8. **A `DATA` line holding a negative number cannot be executed.** §4 settled that "`DATA` at
+8. ~~**A `DATA` line holding a negative number cannot be executed.**~~ **Done** --
+   `akbasic_parse_data()` accepts a unary minus over a numeric literal, which is the only
+   shape that was refused. Deliberately narrow: `DATA -A#` is still a mistake worth naming,
+   and `akbasic_leaf_is_literal()` keeps meaning what it says because it is used elsewhere.
+   `tests/read_data.c` covers reading one *and* walking past the line, which were two
+   different mechanisms and only one of them was ever wrong.
+
+   The original report: §4 settled that "`DATA` at
    run time is now a no-op: it is a declaration, and reaching the statement means walking past
    it." Walking past a negative one raises instead: