gop: RAM backbuffer — scrolling never reads the framebuffer

Real-hardware GOP framebuffers are typically uncacheable or
write-combining (firmware MTRR/PAT), so the scroll shift's full-screen
memcpy *read* ~4-8 MB through uncached memory — a bus round-trip per
cache line.  That made scroll printing crawl on real hardware while
plain printing (a few glyph writes) stayed instant.

- gop keeps a RAM shadow copy of the whole framebuffer (same pitch
  layout), allocated at init.
- Every raster write (glyph blits, clear) goes to both the display and
  the shadow.
- shift_up becomes: cached shadow memcpy up one row + clear exposed
  bottom row in the shadow + one write-only push shadow→display via
  copy_nonoverlapping (64-byte bursts that coalesce on WC memory) —
  the display is never read.
- Fallback to the old direct shift if the shadow allocation is null.

Verified in QEMU: mmap output scrolls ~100 lines with coherent rows
and a clean bottom row, clear wipes the screen, cursor tracks the
prompt, editor paths untouched.  Release + dev builds pass.

0 files changed, 0 insertions, 0 deletions