M2 step 1-2: loader builds bootstrap tables + CR3 handoff

Add the higher-half layout constants (physToVirt/virtToPhys, physmap
and kernel bases) to the danos handoff module, and KernelSegment.phys
so the loader records where it actually placed each segment.

The loader now builds its own page tables before ExitBootServices —
identity + a physmap of low RAM (2 MiB pages) plus 4 KiB mappings for
any higher-half kernel segment — and switches CR3, then calls the entry
with boot_info in RDI, interrupts off. The kernel still links and runs
low (identity), oblivious; this proves the CR3 dance in isolation.
Suite 27/27.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

src/root.zig

@@ -45,6 +45,37 @@ pub const Framebuffer = extern struct {
 /// targets so far.
 pub const page_size = 4096;
 
+/// The kernel's virtual-memory layout (higher-half). The kernel is linked at
+/// `kernel_virt_base` but loaded at a low physical address; all of RAM (and the
+/// device MMIO windows) is also mapped at `physmap_base + phys`, so the kernel
+/// can reach any physical address by adding a constant. The low half is left
+/// entirely to user space.
+///
+///   user image + stack : 0x0000_7000_0000_0000  (PML4[224], low half)
+///   kernel heap        : 0xFFFF_8000_0000_0000  (PML4[256])
+///   physmap            : 0xFFFF_8800_0000_0000  (PML4[272]) + phys
+///   kernel image       : 0xFFFF_FFFF_8000_0000  (PML4[511])
+pub const physmap_base: u64 = 0xFFFF_8800_0000_0000;
+pub const kernel_virt_base: u64 = 0xFFFF_FFFF_8000_0000;
+
+/// Physical address -> its virtual address in the physmap. The single way the
+/// kernel dereferences a physical address once paging is up.
+///
+/// **Hazard:** valid only once the (bootstrap or final) page tables are live.
+/// The bootloader may use the *constant* `physmap_base` to build those tables,
+/// but must not call this to dereference memory before its own CR3 is loaded —
+/// it runs under the firmware's identity map, where these addresses are unmapped.
+pub inline fn physToVirt(phys: u64) u64 {
+    return phys + physmap_base;
+}
+
+/// Physmap virtual address -> physical. Inverse of `physToVirt`; for producing
+/// the physical address of something the kernel holds a physmap pointer to
+/// (e.g. a page-table frame for CR3, a post-mortem breadcrumb's RAM location).
+pub inline fn virtToPhys(virt: u64) u64 {
+    return virt - physmap_base;
+}
+
 /// danos's own classification of a span of physical memory — deliberately not
 /// UEFI's vocabulary. Each boot path (UEFI now, device tree later) translates its
 /// native memory description into these kinds, so the kernel never learns what
@@ -88,9 +119,12 @@ pub const MemoryMap = extern struct {
 
 /// One PT_LOAD segment of the kernel image, so the kernel can re-map itself with
 /// correct permissions (code R+X, rodata R, data R+W+NX). `flags` are raw ELF
-/// segment flags: PF_X=1, PF_W=2, PF_R=4.
+/// segment flags: PF_X=1, PF_W=2, PF_R=4. `virt` is the higher-half link address;
+/// `phys` is where the loader actually placed the segment (they differ once the
+/// kernel links high — the loader records the real load address here).
 pub const KernelSegment = extern struct {
     virt: u64,
+    phys: u64,
     pages: u64,
     flags: u32,
     _pad: u32 = 0,