Bound the transmit spin; retire the probes that have answered

Housekeeping on the instrumentation, plus one fix that stands on its own.

uart.write and uart.writeByte no longer spin forever waiting for TX FIFO space.
hal/uart.zig:182-186 already made this argument about update() - "on a board with
no debugger an infinite spin is indistinguishable from a crash" - and this port
demonstrated it: the console going quiet mid-boot read as a hang in whatever code
came next, for hours, when a stalled transmitter would have looked identical. The
wait is bounded per burst and abandoned bytes are counted in `uart.dropped`, so a
lying console is at least a countable one. The bound is deliberately generous:
1,000,000 status reads against an 11 ms drain at 115200.

Removed, because each has answered its question and the answers are recorded in
comments where they matter:

  * the MMU table dump - the table is CORRECT, entries 0..9 holding 0x1001..0x100a,
    exactly the valid bit plus physical page N+1 that the image builder's anchor
    requires. That is now stated in flushFlashCache's doc comment rather than
    re-measured every boot.
  * the before/after eviction read - it established that the same load returns
    93 85 85 0f before a capacity flush and 3c ee 08 40 after, which is what the
    image holds there. The flush itself stays; the proof of why it is needed is in
    the comment.
  * the allocator and vtable pointer dumps in src/p4.zig - they showed the struct
    crosses the seam intact, with its function pointers landing in .flash.text.
  * the bisect early return - it showed that execution does not come back from
    pardes_p4_init at all.

What is left in place, on purpose: the I1..I10 markers inside pardes_p4_init and
the B1..B9 markers in the firmware. The port does not work yet and they are how
the next person finds out where it stops.

Where it stops: the console goes silent immediately after the editor's
pardes.allocators.init and never resumes. It is not the transmit spin - lowering
the bound to 20,000 and watching for 30 seconds changed nothing - and it is not a
trap the ROM can report, because no Guru Meditation is printed. Execution does not
return from pardes_p4_init even when that function is made to return immediately
after the marker that does print. So the CPU is lost inside a call whose only
work is handing a string to a function pointer, which points at the firmware's own
writeOut. That needs an instrument this setup does not have: JTAG, or a GPIO-based
tracer that does not depend on the UART at all. Everything cheaper has been tried
and is recorded above.

0 files changed, 0 insertions, 0 deletions