v0.5.7: fix vt verify content check — expect BLANK (0x70020), not zero

The pre-verify 0x70020 'mystery' was a debug artifact, not corruption:
BLANK = {ch:32, fg:7, bg:0} = raw 0x70020, and vec![BLANK; n] fills both
grids with it at init.  The old check compared cells against 0 and its
probe loop break-ed on the first non-zero cell, so probes 1-3 stayed at
their zero-initialized slots — c=[0x70020,0,0,0] was bogus on every
healthy boot.  A full-grid dump proves QEMU grids are 100% BLANK at
shell entry (nz=3700 blank=3700).

Fix: probes compare against blank_raw (0x70020), record all four values
(no early break), probe both cells and rendered, and add a full-grid
nz/blank summary line.  The OptiPlex firmware 0x00AAAAAA scrub remains
cleanly distinguishable (scrub != blank).

Markers: the shell banner occupies grid rows 0-1 and the prompt row 2
(proven by screendump), and a stale crash.log replays at rows 2+, so the
shadow and vt markers moved to the bottom of the screen via the new
gop::text_rows()/bottom_row(off) helpers instead of rows 1-2.

QEMU verified: verify: ok every boot; test-msg + test-fault PASS; debug
and release builds 0 warnings.

0 files changed, 0 insertions, 0 deletions