Recomps: a section under Games that catalogues recompilations and builds them on the user's machine, RetComM-launcher style

[cubman3134]

Asked for by the owner: "There is a project called RetComM launcher that catalogs and installs recomps that self compile on the end user's machine. Can you flag an issue for us to do this as well? We should have a new Recomps section under the games category."

What exists

• Native ports: play N64 recompilations (Zelda64Recomp etc.) as one-game standalone launchers #233 increment 1 (merged, 5955f55) put a Native port verb on the one game row a shipped recomp runs (Zelda64Recomp on Majora's Mask): an in-tree catalogue in RetComM's per-title schema plus our rom_delivery extension, install through the standalone-emulator path, ROM supplied per the port's declared mode. That is the pre-built tier: N64 recomps ship as release binaries because N64Recomp needs a per-game decompilation, so there is nothing generic to compile.
• RetComM Launcher (CLI, MIT) is the other tier: a catalogue (retcomm-catalog: index.json + titles/<id>.json, 15 PSX titles today) whose entries name a recompiler engine (snesrecomp / psxrecomp / gbarecomp) and a build recipe, and the launcher compiles the port on the end user's machine from the recompiler plus the user's own ROM. The user never downloads a game binary; the ROM they already own becomes a native executable locally.
• A standalone emulator's argsTemplate cannot express a literal argument containing a space #237 (fixed) removed the one launch-template limitation that blocked command-line ROM delivery.

Proposed behaviour

A Recomps section under the Games category — a first-class browse surface, not only a verb on a game row:

1. Catalogue browse. Rows per recomp, grouped by system (PSX, SNES, GBA, N64 …), each showing: title, engine, licence, install state (not installed / needs ROM / building / ready / update available), and whether it is pre-built (a release binary, Native ports: play N64 recompilations (Zelda64Recomp etc.) as one-game standalone launchers #233's tier) or self-compiled (RetComM's tier). Sources: our in-tree catalogue (Native ports: play N64 recompilations (Zelda64Recomp etc.) as one-game standalone launchers #233) and RetComM's published catalogue consumed as a second feed (its catalog.zip / index.json), merged by title identity, refreshed on a schedule like the other registries. A catalogue document the reader cannot parse presents as an error, not an empty list (An empty registry and a misread registry must not look the same #174 rule).
2. ROM identity gating. A recomp row is installable only when a ROM in the user's library matches the entry's rom_identity (HashVerify against the published hashes) — the same gate Native ports: play N64 recompilations (Zelda64Recomp etc.) as one-game standalone launchers #233 planned for increment 2. Without a match the row says which dump it needs; it never fetches a ROM.
3. Self-compile on this machine. Install of a self-compiled entry = run RetComM's CLI (or the engine it names) as an external process against the user's ROM, with a live build surface: progress, the tail of the build log, cancel, and a readable failure ("the compiler exited with … — full log at …"). Builds run off the GUI thread; the app stays usable; a build survives navigating away and shows in Downloads-style progress.
4. Toolchain. A local build needs a C/C++ compiler (and on Windows the matching SDK). The app detects what is present (MSVC Build Tools / clang / gcc, CMake) and, when something is missing, tells the user exactly what to install and links the official installer — it does not download or install compilers itself, and it does not fall back to a hidden bundled toolchain. Detection results are cached and re-checked on demand.
5. Launch and saves. A built recomp launches through the same standalone-emulator seam Native ports: play N64 recompilations (Zelda64Recomp etc.) as one-game standalone launchers #233 uses (its own exe, ROM handed per rom_delivery, per-game overrides, controller passthrough). Saves stay the port's own; portable.txt-style per-profile layouts where the port supports it. The Recomps row for a built title and the game's own row both offer Play (native).
6. Updates. A catalogue entry with a newer engine or recipe marks the row update available; rebuild is explicit, never automatic, and the previous build is kept until the new one launches once.

Constraints stated up front

• Licensing. psxrecomp is PolyForm Noncommercial: it may be invoked on the user's machine, never bundled or redistributed. Engines are fetched from their own releases at build time, credited by name, and the licence is shown on the row. Do not brand anything "N64Recomp" (its developers asked a third-party launcher to stop).
• No ROMs move. The user's dump is read in place; nothing is downloaded that contains game code.
• Defender. A freshly compiled unsigned exe is exactly what this machine's Bearfoos.A!ml heuristic flags; expect it, surface it as a message with the file path, never as a silent disappearance.
• Catalogue rot. Upstreams rename, 404 and re-tag; data + user override (<data>/ports/*.json) keep that off the build, as Native ports: play N64 recompilations (Zelda64Recomp etc.) as one-game standalone launchers #233 chose.

Relationship to #233

#233's remaining increments (RetComM feed + HashVerify gating, cli_path delivery, install_dir_name, allow_prerelease) are absorbed here as items 1, 2 and 5; #233 stays the record of the pre-built tier and closes when those land under this issue. Increment order: (a) the Recomps section over the existing #233 catalogue with install-state rows; (b) the RetComM feed + hash gating; (c) toolchain detection + the external build with its progress surface, PSX first; (d) updates.

Verification

Probe-pin the catalogue merge, the hash gate, the toolchain detector's decision table and the build-state machine (mutation-tested); live-verify one PSX title compiling from a user-owned dump to gameplay on this machine, with the compile time and disk use recorded in the report.