[Feature] Download Options for Multi-File Games (Patches, Hacks, ES-DE Structure)

Is your feature request related to a problem? Please describe.

RomM excels at organizing complex, multi-file games by recognizing "special folders" like patch, hack, and translation. However, the current download functionality treats the entire game directory as a single unit, downloading everything into a ZIP archive. This is inefficient and lacks flexibility for several common use cases:

1. Redundant Data: A user wanting to play only the base game is forced to download all associated hacks, patches, and manuals, consuming unnecessary bandwidth.
2. Manual Patching Required: To play a patched version of a game, the user must download the entire folder, use an external tool (like Lunar IPS) to apply the patch to a copy of the base ROM, and then manage this new file. This process is cumbersome and leads to storing duplicate, large ROM files.
3. Soft-patching with ES-DE: ES-DE supports “soft-patching,” where a base ROM and a patch file are stored together inside a folder named after the base ROM. This allows RetroArch to automatically apply the patch when launching the game. RomM’s current download method does not produce a structure compatible with this, forcing the user to create it manually.

Describe the solution you'd like

I propose enhancing the download functionality for multi-file games by introducing a "Download Options" dialog. When a user clicks the download button for a game that contains "special folders," instead of an immediate download, a modal would appear offering several choices:

1. Download Original (ZIP): The current behavior. Downloads the entire game directory as a single ZIP archive.

2. Download Main ROM(s) Only:

   • Action: Generates a ZIP containing only the core game files found in the root of the game's directory (e.g., .iso, .cue/.bin, .gba). It would exclude all "special folders" (/patch, /hack, etc.).
   • Benefit: Provides a lightweight download for users who only want to play the original version of the game.

3. Download Pre-Patched Version...

   • Action: If RomM detects patch files (e.g., .ips, .bps, .xdelta) in the special folders, this option becomes available. Clicking it would present a sub-menu listing the available patches. Upon selecting a patch, the backend would apply it to the base ROM on-the-fly and serve the resulting single, patched ROM file for download.
   • Benefit: Allows users to download a ready-to-play patched ROM without needing external tools, perfect for emulators that don't support automatic patching.

4. Download for ES-DE (Soft-Patching)...

   • Action: Similar to the option above, this would present a list of available patches. Upon selection, RomM would dynamically generate and serve a ZIP file with the specific folder structure required by ES-DE for soft-patching.
     • Example Structure: For a hack named "Esmeralda Mejorado," it would create a ZIP containing:
       复制

       Esmeralda Mejorado.gba/
       ├── Esmeralda Mejorado.gba  (The base ROM, renamed)
       └── Esmeralda Mejorado.ips  (The patch file, renamed)

   • Benefit: Bridges the gap between RomM's efficient storage (one base ROM) and the powerful features of other frontends. Users can manage their master library in RomM and easily export ready-to-use versions for their portable devices or desktop setups running ES-DE.

Describe alternatives you've considered

The current alternative is to download the entire game folder and perform all patching and structuring manually. This is inefficient, requires third-party tools, and leads to storing multiple large, patched ROM files on user devices, defeating the purpose of a centralized, organized library.

Additional context

• This feature builds upon RomM's existing strengths. The backend already identifies and categorizes files into types like PATCH, HACK, and TRANSLATION via the RomFileCategory enum. This existing logic can be leveraged to populate the proposed download options.
• For the on-the-fly patching functionality, libraries like RomPatcher.js (which has a Node.js CLI) or equivalent Python libraries could be used on the backend to perform the patching process in a temporary environment before serving the file.
• This behavior could also align with a proposal I previously submitted — issue #2098, “Implement on-the-fly patching for IPS/BPS files”. Both features aim to improve how RomM handles patch files and reduce the need for manual file management outside the application.