fix(raspi): the Pi 5's native path turns the MMU and caches on before any C; bounded mailbox; framebuffer address from dma-ranges

boards/BRINGUP.md R2/R3, FABRIC-3 SXXXIX.  The entry stub cleans the cache
over the image, builds an identity map (the image's GiB Normal, the rest
Device) and enables MMU and caches at EL2 (or EL1); rpi5_mmu.c makes the
devicetree's RAM Normal and the framebuffer uncached.  Mailbox waits give
up after one second; the buffer is cleaned around the exchange; the
framebuffer address goes through dma-ranges, not a Pi 4 mask.

New rpi5-rehearsal target runs the native image on QEMU virt at EL2.  It
found three more that would each have stopped the board: the PL011 shift
(mine, c9519173; the host test asserted it), the GIC address not carried
through /soc's ranges (new fdt_reg_address(), checked against the real
Pi 5 DTB), and no timer IRQ at EL2 (HCR_EL2.IMO/FMO/AMO).

Rehearsal: POST 1052 passed, same parity hash as UEFI.  Standard acceptance
on three ISAs: POST 1052, hash 0x82f4ae7cb2e2d424.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

kernel/include/starkernel/rpi5_mailbox.h

@@ -58,9 +58,11 @@ typedef struct {
  *                driver has been designed against; others are not
  *                refused outright but are unverified).
  * @param out     Populated on success; untouched on failure.
- * @return 0 on success, negative on failure (mailbox node not found
- *         in the DTB, VC firmware rejected the request, or a response
- *         tag came back with an unexpected size).
+ * @return 0 on success, negative on failure: -2 no mailbox node in the
+ *         DTB, -3 the VC firmware rejected the request, -4 a response
+ *         came back empty, -5 no answer within one second (every wait is
+ *         bounded), -6 the devicetree's dma-ranges cannot place the
+ *         framebuffer's bus address.
  */
 int rpi5_mailbox_get_framebuffer(const void* dtb, uint32_t width, uint32_t height,
                                   uint32_t bpp, Rpi5FramebufferInfo* out);