Stop the search index silently hiding games

[lepht]

Follow-up to #2, kept separate so the feature and this correctness fix can be reviewed apart. Based on feat/rom-search, since that's where the search code lives.

The bug

SEARCH_INDEX_MAX was 8192, carrying a comment I wrote claiming that "a card with more roms than this is not a search problem." That's wrong — a full set for a couple of systems reaches it — and past the ceiling games simply stopped being findable, with nothing said about it anywhere in the UI.

It failed worse than dropping a random slice. The cap check sat inside the per-directory readdir loop, so truncation followed directory walk order: whole systems at the tail vanished wholesale rather than a scattered sample. readdir order isn't alphabetical or stable, so which systems disappeared could change when the card was written to.

Reproduced on a 34,066-ROM card: planted a uniquely-named game in the last directory readdir returned, and searching for it gave zero results while the file sat on the card.

The fix

Raise the ceiling to 32768. An indexed entry measures ~200 bytes of heap — measured with mallinfo2 around the build over a 6,020-entry index, 1205328 bytes = 200.2 bytes/entry — so the new ceiling is worth ~6.5 MB. That memory is held only while the menu is up: queueNext() writes the command to /tmp/next and sets quit = 1, and the launcher shell loop runs the emulator only after nextui.elf has exited, so the index can't take memory from a game. The ceiling is really a brake on how long the first search waits for the card, not on memory.

Then make hitting it visible instead of silent:

• The walk stops at the top level once full, instead of reopening every remaining system just to bail out of it again.
• The match count renders as 32746+ — a floor, not a total.
• An empty result off a capped index reads No matches / some games are not indexed, which is the one case where a bare "No matches" would be a lie.

Testing

Desktop build driven headless under Xvfb, four cases by screenshot:

card	query	count pill	empty message
34,066 ROMs (capped)	no hits	0+	"No matches / some games are not indexed"
34,066 ROMs (capped)	32,746 hits	32746+	—
65 ROMs (normal)	4 hits	4	—
65 ROMs (normal)	no hits	0	"No matches"

The truncation log line fires exactly once on the capped card and never on the normal one, so behaviour is unchanged for ordinary libraries.

Still open

The first-search walk cost is unmeasured on hardware. On this x86 host it's 9.5–17 ms warm and 32 ms cold at ~6k games, but the walk is I/O-bound and a microSD is a different machine entirely. If it turns out slow enough to be felt, the answer is feedback during the build rather than a smaller ceiling — filed separately rather than guessed at here.