Let a program ask how big the text grid is

`RGR(1)` and `RGR(2)` gave the window in pixels and nothing gave columns, rows
or the cell size -- so anything placing a character *and* a sprite at the same
spot had to hardcode a number measured by hand against whatever font the host
loaded. The Breakout in examples/ does exactly that, `CW# = 16`, and it is the
one thing in that listing that breaks on a different font or window.

**`RWINDOW` is BASIC 7.0's own answer and had never been implemented here.**
`RWINDOW(0)` is the current text window's rows and `RWINDOW(1)` its columns.
`RWINDOW(2)` reports a C128's 40 or 80 column screen mode, and this interpreter
has neither -- refused by name, because answering 0 would be a plausible lie,
which is worse than a refusal that says why.

The cell size in pixels is `RGR(3)` and `RGR(4)`, beside the surface's own
dimensions rather than on `RWINDOW`. Two reasons: a cell size is a fact about
the surface, and `RWINDOW` reports the *window*, so dividing `RGR(1)` by a
column count stops being right the moment a program calls `WINDOW`.

Both read a new optional `grid` entry point on `akbasic_TextSink` -- columns,
rows, cell width, cell height -- implemented by the akgl sink and forwarded by
the tee, in the shape `moveto` and `window` already had. NULL everywhere else,
so both verbs refuse by name against a sink with no grid. `akbasic_sink_init_
stdio()` clears it for the same reason it now clears the other two.

Measured on the standalone build: `RGR(3)` answers 16 and `RWINDOW` answers 50
columns by 37 rows -- the three numbers the Breakout listing had written out as
constants -- and `RWINDOW` follows a `WINDOW` call while `RGR(3)` does not.

tests/console_verbs.c drives the answers through a stand-in sink with a grid,
since the harness sink is stdio and has none; tests/graphics_verbs.c covers the
new `RGR` fields, their refusal, and the moved range bound. The `c excerpt=`
block in docs/10-embedding.md moves with the header, which is `docs_examples`
doing its job.

TODO.md section 6 item 31's second half, struck.

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

docs/06-graphics.md

@@ -180,10 +180,29 @@ it off and coordinates go back to being window pixels.
 
 `RGR(0)` is the current `GRAPHIC` mode. `RGR(1)` and `RGR(2)` are the drawing
 surface's width and height in pixels — those two are ours rather than 7.0's, and they
-are what a program needs to use a window whose size it did not choose. All three
-refuse when there is no graphics device, except `RGR(0)`, which is a mode this
+are what a program needs to use a window whose size it did not choose. They
+refuse when there is no graphics device, unlike `RGR(0)`, which is a mode this
 interpreter recorded rather than a screen it has to go and measure.
 
+**`RGR(3)` and `RGR(4)` are a character cell's width and height**, also ours. They come
+from the *text* device rather than the graphics one — a character grid belongs to the
+sink — so they refuse by naming that instead. Between them and
+[`RWINDOW`](12-function-reference.md), which gives the current text window in columns
+and rows, a program can place a character and a sprite at the same spot without
+hardcoding a number measured against whatever font the host loaded:
+
+```basic requires=akgl
+10 CW# = RGR(3)
+20 CH# = RGR(4)
+30 COL# = 12
+40 ROW# = 3
+50 CHAR 1, COL#, ROW#, "X"
+60 MOVSPR 1, COL# * CW#, ROW# * CH#
+```
+
+`RWINDOW` follows a `WINDOW` call, because it reports the window. `RGR(3)` and `RGR(4)`
+do not, because windowing does not change how big a character is.
+
 ### WIDTH
 
 `WIDTH 1` or `WIDTH 2` sets how thick a drawn line is. A thick line is drawn as