feat: global rom search in the quick menu

[lepht]

A global ROM search reachable from the quick menu, in the spirit of the stock TrimUI OS.

Stacked on #1. Base is feat/favorites, so this PR shows only its own commit. GitHub will retarget it to main automatically when #1 merges. The dependency is real, not just ordering: the Y-to-favorite binding in the results calls openContextMenu, and the indexer reuses isGameDir / isDirectory from that branch.

What this does

A Search entry in the quick menu opens an on-screen keyboard over a live result list. It indexes every ROM under Roms/ for which an emulator pak exists, honouring the same hidden-file and map.txt alias rules the browser uses, and treating a multi-disc folder as one game rather than a pile of discs. The index is built once, on the first visit.

The two halves hand focus back and forth: walking off the top of the keyboard moves into the results, which then take the keyboard's space so a long list can be browsed full-screen; walking off the bottom of the results gives it back. A launches, X resumes a save state, Y opens the same context menu the game lists use — so a game can be favorited straight out of a search.

Games that exist under two systems are tagged with the emulator they belong to, exactly like a directory listing does.

The query field behaves like a text field rather than an append-only buffer. L/R move a cursor through it a character at a time, typing inserts at the cursor, and X deletes the character before it — so a typo in the middle of a query doesn't mean backspacing over everything after it.

Reopening search starts on the previous query with the whole thing selected, the way a desktop text field does: START runs it again as-is, and typing replaces it outright. Moving into the results, by START or by walking up off the keyboard, accepts the query and drops the selection. The query lives in /tmp next to last.txt, so it survives launching a game — which is what exits nextui, and therefore the case that matters — but not a reboot.

Layout decision

At the Brick's 341×256 logical space there isn't room for a query field, a full result list, a keyboard, and the button hints at once. Rather than shrink everything, the result list and keyboard trade space based on focus: ~3 preview rows while typing, ~5 with the keyboard hidden. Row counts are computed from the actual screen height rather than hardcoded, so this adapts to other panels.

A button-hint group fits two hints at most, so the hints are contextual rather than crowded: a carried-over query spends them on the choice it presents (START SEARCH, A REPLACE), and the editing hints (Y SPACE, X DELETE, A TYPE) come back as soon as the selection is gone.

Testing

Built the desktop target and drove it under Xvfb against a fake SD card (~25 ROMs across 7 systems), verifying by screenshot:

• live filtering as characters are typed, with a live match count in the query pill
• focus handoff in both directions, and the row count changing with it
• paging through a 19-result list and landing correctly on the last item
• the empty states (Type to search vs No matches)
• a multi-disc PS1 folder indexed as one result, not three
• launching from results (correct emulator command queued, correct recents entry written)
• opening the context menu on a result and favoriting from there

The query field was verified the same way, against a generated library of ~200 ROMs across 14 systems:

• reopening restores the previous query, drawn selected, with its results already filtered
• START runs the carried-over query and hands focus straight to the results
• a keypress replaces the whole selection; L/R collapse it to either end instead, keeping the text
• the cursor steps character by character, inserting mid-string and deleting the character before it
• the query survives a game launch — written on exit, restored on the next run

Also exercised under AddressSanitizer with zero errors. Passes -fsyntax-only against both the tg5040 and tg5050 platform headers.

Not tested on hardware.

One note for anyone else driving the desktop build: PAD_poll drains the whole SDL event queue per call, so a synthetic instant keytap can have its press and release land in the same poll, which clears just_repeated while leaving just_pressed set — silently swallowing every d-pad and L/R input. Holding each key ~150ms avoids it. Real buttons are held across many polls, so this is a harness artifact only.

Performance note

The index is built synchronously on first open. On this test library it's imperceptible; on a card with thousands of ROMs it's a readdir/stat walk that could produce a brief hitch on that first visit. Capped at 8192 entries. If it turns out to matter on a real card, the walk is self-contained enough to move onto the existing loader thread.

Refs LoveRetro#110, LoveRetro#589