fonts: the picker showed 512 faces on a machine with a thousand

max_fonts was 512 and this desktop has 1071 monospace faces installed. The
walk stopped at the cap, and because the sort runs AFTER the cut, the picker
did not look truncated -- it ran A to z with four hundred faces missing out of
the middle of it, which is a far worse way to be wrong than a short list.

The cap is now 4096 and the array comes from the arena rather than the stack:
4096 * {name, path} is 128 KiB, which is a fine thing to hand an arena that
resets at the end of the keystroke and not a thing to put on a call stack. It
was only ever a MEMORY bound anyway -- the work is bounded by max_steps, since
a face has to be walked past before it can be found -- and the comment now
says so instead of implying the number was about how long a list can be read.

Costs nothing measurable: the walk is what takes the time, not the four sfnt
reads per file. 512 faces warm was 31ms, 1071 is 36ms. (The 11s I first
measured was a cold page cache reading every font file on the disk once.)

Two guards, because the reason this went unnoticed is more interesting than
the off-by-a-cap:

- src/fonts.zig is imported behind `platform == .gui or .macos`, so on the tty
  build nothing analyses it and zig collected no tests from it. It HAD tests;
  they never ran. It now has its own libc-linked module in unit-test, which is
  the hazard build.zig already writes down next to shell_bin.zig.
- a canary test asserting installed.len < max_fonts. Reaching the cap means
  the list handed to the picker is a lie, and it should fail loudly rather
  than quietly serve half a machine. Verified it fails at 512 and passes at
  4096.

Verified in a real SDL window: SPC t f then a dump, 1092 rows in +Fonts.
unit-test 186/186 (5 of them newly reachable).

0 files changed, 0 insertions, 0 deletions