rpi5_dtb.c: wire fdt.c's node-scoped lookup into the Pi 5 UART/mailbox addresses

New include/starkernel/rpi5_dtb.h / src/starkernel/arch/aarch64/rpi5_dtb.c:
rpi5_uart_base()/rpi5_mailbox_base(), each finding their peripheral by
compatible string ("arm,pl011" / "brcm,bcm2835-mbox") via fdt_find_node_by_
compatible() then reading its "reg" via fdt_find_prop_in_node().

Found and fixed a real translation gap before it could have silently
produced a wrong address: confirmed directly against bcm2712.dtsi
(raspberrypi/linux) that both peripherals live under one "soc"
simple-bus node whose ranges property adds a fixed 0x10_0000_0000
offset to every child reg value. fdt.c's reader deliberately doesn't
apply ranges translation generally (not a general devicetree
library); this file applies that one, fixed, SoC-wide offset
explicitly, documented with the exact devicetree excerpt that
confirmed it.

Compile-only verification -- no caller wired in yet, these two
functions are what the still-open entry-stub and mailbox-framebuffer-
driver punch-list items will call. Verified 3-arch boot to ok>
(amd64/aarch64/riscv64, each in the foreground; rpi5_dtb.o confirmed
built on aarch64, the only arch that compiles this file).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019YcT3H2PQeyujrzjqS3Var

FABRIC-3.md

@@ -318,15 +318,29 @@ blocker for free.
    the crux of why most of M1–M9 stays shared.
 3. **Mailbox-property-interface framebuffer driver** — genuinely new code (§IV.1's own
    assessment), populating `BootInfo.framebuffer` the same shape UEFI GOP currently does, so
-   `console.c`/`vt100.c`/`framebuffer.c` need no changes at all downstream.
+   `console.c`/`vt100.c`/`framebuffer.c` need no changes at all downstream. **The address
+   lookup half is now done** — see item 4a below; the mailbox message-protocol half (framing
+   a real property-tag request/response over the discovered base address) is still open.
 4. **`fdt.c`/`fdt.h` extension — DONE 2026-09-04.** Added `fdt_find_node_by_compatible()`
    (matches any entry in a node's NUL-separated `compatible` list, first match in document
    order) and `fdt_find_prop_in_node()` (scoped to that one node's own direct properties only
    — stops at the first child node or the node's own end, never descends or continues into a
    sibling). Same minimal, non-tree-building style as the existing reader — no new state, no
-   allocation, one linear scan per call. Verified 3-arch boot to `ok>` (compile-only — no
-   caller wired in yet; this is the shared primitive items 1/3 above and §V.3 item 3 below
-   will each call once built).
+   allocation, one linear scan per call. Verified 3-arch boot to `ok>`.
+
+   **4a. UART + mailbox address lookup — DONE 2026-09-04.** New
+   `include/starkernel/rpi5_dtb.h` / `src/starkernel/arch/aarch64/rpi5_dtb.c`:
+   `rpi5_uart_base()`/`rpi5_mailbox_base()`, each `fdt_find_node_by_compatible()` (`"arm,pl011"`
+   / `"brcm,bcm2835-mbox"`) → `fdt_find_prop_in_node(..., "reg", ...)`. **A real translation
+   gap found and fixed before this could have been silently wrong**: confirmed directly
+   against `bcm2712.dtsi` (raspberrypi/linux) that both peripherals live under one `soc`
+   simple-bus node whose `ranges` property adds a fixed `0x10_0000_0000` offset to every
+   child `reg` value — `fdt.c`'s reader deliberately does not apply `ranges` translation
+   generally (not a general devicetree library), so this file applies that one, fixed,
+   SoC-wide offset explicitly by name (`BCM2712_SOC_RANGES_OFFSET`), documented with the exact
+   devicetree excerpt that confirmed it. Verified 3-arch boot to `ok>` (compile-only — these
+   two functions have no caller yet; that's the entry-stub/framebuffer-driver items above,
+   still open).
 5. **`pci_init()` DTB path**: a devicetree-based alternative for RP1 discovery, since
    `boot_info->acpi_table` will be `NULL` on this path and RP1 is PCIe-attached, not directly
    memory-mapped.