rpi5_mailbox.c: wire the VideoCore mailbox message protocol (FABRIC-3.md §IV.3 item 3)

New rpi5_mailbox_get_framebuffer() sends one property-tag request buffer
(phys size, virt size, depth, pixel order, virtual offset, allocate-buffer,
get-pitch) over the register layout rpi5_dtb.c already discovers, populating
an Rpi5FramebufferInfo kept in exact field-for-field sync with uefi.h's
FramebufferInfo so console.c/vt100.c/framebuffer.c need no downstream changes
once this is wired into a real entry stub.

Register offsets (+0x00/+0x18 MBOX0 read/status, +0x20/+0x38 MBOX1
write/status) confirmed against a Pi-5-specific bare-metal reference,
independently cross-checked against this codebase's own rpi5_dtb.c
translated base address.

Caught and fixed a real buffer-overflow bug before compiling: the static
request buffer was sized 32 words against an actual 35-word requirement for
the 7-tag sequence, recomputed exactly rather than re-estimated; resized to
40 words.

Two things flagged as genuinely unverified against real hardware (not
guessed past the comment): the allocate-buffer tag's request-size field
value, and whether its response address needs classic bus-alias masking on
Pi 5 specifically.

Compile-only-verified -- no caller yet (that's the still-open entry-stub/DTB
constructor items). Verified 3-arch boot to ok>/zuse)ok>.

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

FABRIC-3.md

@@ -316,11 +316,25 @@ blocker for free.
    from DTB `/memory`+`/reserved-memory`, the mailbox interface (next item), and DTB `/chosen`
    `bootargs` respectively. Then calls the **existing, unmodified** `kernel_main()` — this is
    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. **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.
+3. **Mailbox-property-interface framebuffer driver — DONE 2026-09-04.** New
+   `include/starkernel/rpi5_mailbox.h` / `src/starkernel/arch/aarch64/rpi5_mailbox.c`:
+   `rpi5_mailbox_get_framebuffer()` builds and sends one property-tag buffer (phys size, virt
+   size, depth, pixel order, virtual offset, allocate-buffer, get-pitch), populating an
+   `Rpi5FramebufferInfo` kept in exact field-for-field sync with `uefi.h`'s `FramebufferInfo`
+   so `console.c`/`vt100.c`/`framebuffer.c` need no changes downstream. Register layout
+   (`+0x00`/`+0x18` MBOX0 read/status, `+0x20`/`+0x38` MBOX1 write/status) confirmed against a
+   Pi-5-specific bare-metal reference (main.lv), independently cross-checked against this
+   codebase's own `rpi5_dtb.c` translated base address — two independent sources agreeing. A
+   real buffer-overflow bug was found and fixed before compiling (the static request buffer
+   was sized 32 words against an actual 35-word requirement, recomputed exactly rather than
+   re-estimated; resized to 40 words for margin). **Two things flagged, not guessed, as
+   genuinely unverified against real hardware:** the `TAG_ALLOCATE_BUFFER` tag's request-size
+   field value (set to the response size, matching common practice across surveyed reference
+   implementations, not a single spec-quoted number); and whether the allocate-buffer
+   response address needs the classic `& 0x3FFFFFFF` bus-alias masking on Pi 5 specifically —
+   kept defensively even though the same Pi-5-specific send-side reference found no bus-alias
+   bit in play there. Verified 3-arch boot to `ok>`/`zuse)ok>` (compile-only — no caller yet;
+   that's the entry-stub/DTB-constructor items above, 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