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.

1 files changed, 3 insertions, 3 deletions

diff --git a/Cargo.lock b/Cargo.lock
index 65166d4..2796caa 100644
--- a/Cargo.lock
+++ b/Cargo.lock
@@ -4,7 +4,7 @@ version = 4
 
 [[package]]
 name = "rsdos"
-version = "0.5.3"
+version = "0.5.4"
 dependencies = [
  "rsnix",
  "shell",
@@ -19,11 +19,11 @@ dependencies = [
 
 [[package]]
 name = "rsnix"
-version = "0.5.3"
+version = "0.5.4"
 
 [[package]]
 name = "shell"
-version = "0.5.3"
+version = "0.5.4"
 dependencies = [
  "rsdosedit",
  "rsnix",