fix silent RX drops: enlarge ring to 4 KiB, add drop counters

[cpunt]

The issue

The software RX ring between the PL011 ISR and the foreground reader is
hard-coded to 128 bytes in uartx/ringbuffer.go:

const bufferSize uint8 = 128

At 115200 baud a byte arrives every ~87 µs, so 128 bytes is only
~11 ms of headroom between the interrupt producer and the foreground
consumer. Any stall longer than that on the consumer side causes
Buffer.Put() inside handleInterrupt to start returning false, at
which point bytes are silently discarded. The existing ISR code even
acknowledges the drop path:

if uart.Buffer.Put(byte(r & 0xFF)) {
    enq++
} else {
    // optional rxDrops++
}

…but the counter was never implemented, so applications had no way to
detect the loss. The symptom downstream is mid-frame data corruption
with no error path back to the caller.

How we hit it

We use this driver for a full-duplex fabric link between a CM5 host
and an RP2350 MCU at 115200 8N1, running a stop-and-wait firmware
update protocol that ships ~800-byte JSON chunks, writes each chunk
to flash on the MCU, acks, and waits for the next one.

The MCU side does a flash page program (5–10 ms) per accepted chunk,
plus occasional TinyGo GC cycles and periodic logger bursts. Any one
of those events pushed total foreground latency above the 11 ms
headroom and caused bytes to vanish from the middle of the next
incoming frame. Two surface symptoms:

1. Single truncated frames — a JSON object arrived with a short
   data field (typically 76–96 bytes missing); sender and receiver
   both claimed the full chunk length.
2. Merged frames — when the lost bytes happened to include the
   \n terminator, our line assembler kept reading past the broken
   frame and glued the sender's retry of the same seq onto the broken
   copy. We would see types=xfer_chunk,xfer_chunk seqs=N,N on the
   receive side.

Both classes disappeared the moment the RX ring was resized.

The fix

1) uartx/ringbuffer.go — widen and enlarge

• bufferSize promoted from uint8 = 128 to uint16 = 4096.
• head / tail switched from volatile.Register8 to
  volatile.Register16 so sizes above 255 work without wraparound
  ambiguity.
• Size() and Used() now return uint16.

4096 is still a power of two so (h+1) % bufferSize compiles to a
bitmask. It gives ~355 ms of headroom at 115200 (scales linearly with
baud), which is enough to absorb any realistic foreground stall on
the MCUs this package currently targets. The extra RAM cost is
2 × (4096 − 128) = 7.75 KiB per UART instance (RX + TX ring); on a
dual-UART RP2350 config that is ~16 KiB total, negligible against the
520 KiB SRAM budget.

2) uartx/rp2_uart.go — drop counters

• Two new fields on UART: rxHwDrops and rxSwDrops, each a
  volatile.Register32.
• handleInterrupt increments rxHwDrops in the existing branch
  that drops PL011 error bytes (the most informative of OE/BE/PE/FE
  is UARTDR_OE, which means the hardware FIFO overflowed before the
  ISR could service it), and increments rxSwDrops when
  Buffer.Put returns false.
• The ISR is the only writer so the non-atomic read-add-write
  sequence is race-free on a single core. On a dual-core MCU the
  reader may see a slightly stale value but aligned 32-bit
  loads/stores remain atomic.

3) uartx/uartx.go — public accessor

New (*UART).RXDrops() (hw, sw uint32) so applications can surface
the counters in whatever telemetry / logging they already have. In a
healthy deployment at the supported bauds both values should stay at
zero; a nonzero hw means the ISR latency is exceeding one character
time, and a nonzero sw means the application consumer is not
draining the ring fast enough.

Compat notes

• RingBuffer.Size() and RingBuffer.Used() return type changed
  from uint8 to uint16. Every caller in this repo — including
  the Buffered() and TxFree() wrappers — already goes through
  int(...), so there is no in-repo break. External callers that
  explicitly stored the result as uint8 will need to widen the
  type. The package has no tagged release yet, so no semver break.
• Total static RAM increase on a typical RP2350 dual-UART config is
  ~16 KiB. Trivial against the chip's 520 KiB SRAM.

Verification

• tinygo build -target=pico2 ./cmd/uart_diag — builds cleanly with
  the uint16 widening.
• tinygo build -target=pico2 ./examples/simple/uartx-polling —
  builds cleanly; the example's Buffered() call is unaffected.
• End-to-end downstream: a 336 KiB firmware-update transfer over
  115200 that used to corrupt 15–20 frames per run and take 60–180 s
  with retries now runs clean in ~55 s (stop-and-wait protocol floor)
  with rxHwDrops == rxSwDrops == 0 across the entire transfer.

Follow-ups (not in this PR)

• Consider making bufferSize configurable via UARTConfig for
  callers who care about RAM more than headroom. That would require
  moving the ring from a fixed-size array to a slice and is a
  larger change.
• Consider normalising Size() / Used() / Buffered() to all
  return int so the width is never a compat concern again.

[cpunt]

Closed as moved up in layers jangala-dev/devicecode-go#40