fix: scrollback rows keep their push width (heap over-read); repair the gate

A history row is allocated at the cols in effect when it scrolled off and is never re-widthed (xterm no-rewrap). Every reader used a GUESSED width instead of the row's own, so widening the terminal after content scrolled into history read past the allocation:

  nat_scrollback_row    guessed t->cols   wrong on any widening resize
  nat_scrollback_runs   guessed t->cols   wrong on any widening resize
  resize_grid pull      guessed ocols     wrong after TWO resizes (push@40 ->
                                          80 -> 132 reads 80 cells from a
                                          40-wide row)

Reproduced: a 40-col terminal with 26 history rows, resized to 132, returns a 132-element row from a 40-wide allocation; 45 of the 92 out-of-bounds cells hold invalid codepoints. That is ~1.4KB of adjacent heap per row, and it gets RENDERED: in Slate it either crashes the frame (integer->char rejects the garbage, so take-frame dies and the pane stops updating) or, on a runs-based renderer, silently paints adjacent heap into the DOM. Reachable by ordinary use: run something that scrolls, widen the pane, scroll back. Confined to the app's own wasm linear memory (verified: no wasm trap, no cross-origin reach), but a native consumer such as the planned sigil-tui has no such sandbox.

Root cause is one thing, not three. The interpreted reference is safe by construction: resize-row reads (vector-length row), because a Scheme vector carries its length. Porting rows to raw int32t* dropped that length, and each reader then had to invent it. Fix: store the push width per ring entry (sbw) and make every reader use it. The comment asserting ring rows "are only read during pull (min-copied) - safe" is corrected; it stopped being true when the render seam added readers, and the pull's own min-copy was wrong anyway.

test/vt-test.sgl: three regression tests covering both readers and the pull. Each was confirmed to FAIL against the unfixed core before being trusted. One of them initially passed on the bug because it asserted per-RUN text length, and over-read garbage splits into many short runs; it now asserts the TOTAL.

THE GATE ITSELF WAS BLIND, which is why this shipped. spike/fuzz.sh reported "5,000,000 iterations, ASan/UBSan clean" with NO ASan present: the pinned zig has no ASan runtime, so -fsanitize=address alone fails to link (undefined asanreportload4) and -fsanitize=address,undefined links while silently dropping it (zero asan symbols in the binary). A 1456-byte heap over-read goes undetected. UBSan was real and useful; ASan was never there. Two fixes:

  - vt-fuzz.c walked only sb[0] of a scrollback row (always in bounds). It now
    walks the full row at sb_get_w. Necessary but NOT sufficient: with the full
    walk pointed at t->cols, 150k iterations still passed on this toolchain,
    because the missing ASan is the real reason the bug survived.
  - fuzz.sh now self-tests BEFORE trusting itself: it compiles a known
    cross-function heap over-read with the same flags and refuses to run if the
    sanitizer fails to catch it. A naive self-test would pass on this broken
    toolchain, because an in-function malloc lets UBSan's object-size check
    fire and masquerade as ASan; the probe is deliberately opaque.
    SAN_UBSAN_ONLY=1 keeps the real UBSan coverage available, loudly labelled,
    never reportable as the M2 memory-safety gate.