v0.5.5: fix real-hardware boot crash — shadow back in heap as first allocation

User's machine: boot reached 'rsnix: boot done — shell' then panicked
'len is 0, index 0' at the first cell write — CELLS (the vt grid) was
valid at vt::init and empty at the first shell paint, i.e. something
stomped the heap between vt::init and the shell banner.  The only
change in that window vs the working v0.5.3 was the v0.5.4 move of the
1.9 MB display shadow from the heap to the fb-aware page allocator:
on this machine's memory layout the page-allocator shadow's fill loop
(480K words) clobbered the heap's vt vectors.

- Shadow is again the *first* heap allocation, in gop::init before
  vt::init builds its grids (the v0.5.3 layout that provably boots on
  the user's hardware) — nothing else in the heap can collide with it.
- init_heap now splits the free list at the GOP framebuffer hole
  instead of subtracting its size from one block that still *spanned*
  the hole — no heap allocation of any size can land on the display.
- Kept the panic-proof try_reserve + fb-overlap rejection + no-shadow
  warning band; dropped the late init_shadow() call in main.rs.
- Verified on QEMU: shadow @ 0x1980020 origin=heap, allocated before
  vt::init, fb clean at 0x80000000; all 5 suites PASS; 0 warnings.

0 files changed, 0 insertions, 0 deletions