v0.5.4: shadow backbuffer can no longer alias the framebuffer

Real-hardware scroll freeze (no exception, QEMU-clean) — the per-word
push (0.5.3) did not fix it, so the wedge is upstream of the push.

A QEMU slow-display simulation (new DISPLAY_STALL knob + shell 'stall'
command busy-waits per display store, mimicking an uncached real-GPU
framebuffer) proved the per-word push and shadow memmove are slow but
finite — the shell keeps ticking, scrolls eventually complete.  The
freeze mechanism QEMU cannot exhibit is the shadow *landing on the
framebuffer*: the heap free list spans the fb hole, so the 1.9 MB heap
shadow can alias the display on machines where firmware reports the fb
as ConventionalMemory — every scroll then becomes an MMIO->MMIO memcpy
on an uncached framebuffer, which wedges real hardware (a stall, no
fault, hence no dump).

Fix:
- gop::init_shadow(): allocate the shadow from the fb-aware page
  allocator (init_page_allocator marks fb pages used per-page), so it
  can never overlap the display; heap allocation kept only as a
  fallback with an explicit overlap rejection.  Boot log now prints
  'gop: shadow @ <addr> ... origin=page-alloc|heap|none'.
- Scroll shadow memmove converted to per-word stores (belt and
  suspenders — immune to any future fb-aliased shadow).
- Verified on QEMU: shadow @ 0x100000 vs fb 0x80000000..0x801d5000,
  overlap=false; all 5 test suites pass; scroll completes even under
  the stalled-display simulation.

0 files changed, 0 insertions, 0 deletions