fdt.c: node-scoped lookup extension (FABRIC-3.md SSIV.3/SSV.3 shared item)

Adds fdt_find_node_by_compatible() and fdt_find_prop_in_node() to the
minimal FDT reader -- the extension fdt.h's own header comment already
flagged as a known future need ("item 0.6 will need node-scoped reg
lookups"), now with real consumers: the Pi 5's UART/mailbox register
addresses (native boot, no ACPI) and the Milk-V Mars's real PLIC base
address (currently hardcoded to QEMU-virt's own value).

fdt_find_node_by_compatible() matches any entry in a node's
NUL-separated "compatible" list, first match in document order.
fdt_find_prop_in_node() scopes to that one node's own direct
properties only -- stops at the first child node or the node's own
end, per the DT spec's ordering guarantee that a node's properties
always precede its children. Same minimal, non-tree-building,
single-linear-scan-per-call style as the existing reader; no new
state, no allocation.

Compile-only verification -- no caller wired in yet, this is the
shared primitive both boards' own punch-list items will call once
built. Verified 3-arch boot to ok> (amd64/aarch64/riscv64, each in
the foreground).

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

FABRIC-3.md

@@ -319,13 +319,14 @@ blocker for free.
 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.
-4. **`fdt.c`/`fdt.h` extension**: today's reader only supports "first match anywhere in the
-   tree" (`fdt_find_prop`'s own doc comment) — sufficient for the single global properties
-   used so far (riscv64's `timebase-frequency`), **not** sufficient for node-scoped lookups
-   (a specific peripheral's own `reg` address, e.g. UART or the mailbox registers) once more
-   than one node could plausibly define a same-named property. `fdt.h`'s own header comment
-   already flagged this as a known future need ("item 0.6 will need node-scoped `reg`
-   lookups... may extend this") — this is that extension, now with a real consumer.
+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).
 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.
@@ -426,9 +427,12 @@ it doesn't. This is a real punch-list item, not a hypothetical.
    pointer, `acpi_table`=`NULL`, memory map from DTB `/memory`+`/reserved-memory`, `args` from
    `/chosen`/`bootargs`.
 3. **PLIC base address: make it DTB-discovered**, not the current QEMU-virt-specific
-   constant — the one concrete, already-flagged risk above. Uses the same `fdt.c` node-scoped
-   lookup extension §IV.3 already scopes for the Pi 5's UART/mailbox addresses — one extension,
-   two consumers.
+   constant — the one concrete, already-flagged risk above. `fdt.c`'s node-scoped lookup
+   extension (§IV.3 item 4, **DONE 2026-09-04**, shared with the Pi 5's UART/mailbox
+   addresses) is the primitive this calls
+   (`fdt_find_node_by_compatible(fdt, "sifive,plic-1.0.0")` → `fdt_find_prop_in_node(..., "reg", ...)`,
+   plausible compatible string, not yet confirmed against the Mars's real DTB) — the actual
+   PLIC-init call site update is still open, only the primitive it needs now exists.
 4. **Framebuffer for HDMI output**: JH7110's display path is genuinely unresearched this
    pass — unlike the Pi 5's mailbox interface (well-documented, reused across many Pi bare-
    metal projects), no equivalent research done yet for JH7110's own display controller.