dma: best fit, and say which number is the problem

The arena hands out contiguous memory -- that is the only reason it exists --
so the number that matters is not how much is free but how big the largest
piece is. First fit spends that number cheaply: a 64 KB ring taken from the
middle of a 16 MB arena leaves two 8 MB extents, and a framebuffer wanting 9 MB
then cannot be had on an arena three quarters empty.

dma_alloc() is best fit now: the tightest extent that holds the request, which
leaves the large ones whole for the requests that have no alternative. O(n)
over a table with a handful of entries, and it cannot fragment worse than first
fit for any request.

And the failure says both numbers, because they point at different fixes and
the old message only had one of them:

    dma_alloc: no room for 9216000 bytes -- 12591104 free,
               largest contiguous piece 8495104 (`schdbg dma` for the map)

"12 MB free" alone reads as out-of-memory on a machine that has plenty; the gap
between the two is the whole story. A fragmented arena is cured by whoever is
holding the block in the middle letting go, a full one by DMA_ARENA_BYTES.

Also fixes a real bug found while reading it: when the extent table was full,
the tail-split path did `continue` while still holding the lock and having
already committed the extent to the caller -- so it carried on scanning, and
could return a second block or fall through to the failure path having handed
one out. It now returns the block it committed, and says so.

**This does not close the report it came from.** vgpud failing to get a
framebuffer was not reproduced here: at 1280x800 the arena has 8.1 MB
contiguous against a 4 MB request. What is fixed is that the next occurrence
explains itself instead of saying "not enough DMA memory" on an empty arena.

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

docs/architecture/devices.md

@@ -94,6 +94,23 @@ first minute".
 which is precisely what it cannot work out for itself, and the memory comes from
 an arena reserved at boot before the general allocator gets anything.
 
+Everything in that arena has to be **contiguous**, which is the whole reason it
+exists — so the number that matters is not how much is free but how large the
+biggest piece is. `dma_alloc()` is therefore best fit rather than first fit: a
+64 KB ring taken from the middle of a 16 MB arena leaves two 8 MB extents, and
+a framebuffer wanting 9 MB then cannot be had on an arena three quarters empty.
+Best fit puts each request in the tightest extent that holds it and leaves the
+large ones whole for the requests with no alternative.
+
+A failed allocation reports both numbers for the same reason, because they
+point at different fixes — a fragmented arena is cured by whoever holds the
+block in the middle letting go, a full one by `DMA_ARENA_BYTES`:
+
+```
+dma_alloc: no room for 9216000 bytes -- 12591104 free,
+           largest contiguous piece 8495104 (`schdbg dma` for the map)
+```
+
 **Interrupts arrive by `read()`**, the way Linux's uio does it and for the same
 reason: a descriptor composes with `poll`, and a driver that stops reading falls
 behind rather than losing events. The kernel masks the line when the interrupt