[Bug] File category is derived from any path segment at any depth, and enum order decides which one wins

RomM version Observed on 5.2.0. The code path is unchanged on main at the time of writing.

Describe the bug category_for_path_parts() in backend/handler/filesystem/roms_handler.py matches a category name against every segment of a file's path relative to the library root. Two consequences follow:

1. A folder deep inside a console dump whose name happens to equal a category name (game, demo, patch, mod, …) tags its files with that category, although they are ordinary game data. Wii U and Switch dumps routinely carry such folders inside content/.
2. The result is the first match in RomFileCategory enum order, not the outermost folder. Since GAME is first in the enum, a bare game/ segment anywhere in the path outranks a genuine update/ or dlc/ folder above it.

To Reproduce

roms/wiiu/Some Game/
└─ Some Game [Update]/
   └─ content/
      └─ Game/
         └─ Stats/
            └─ archive.bin       ->  category: game

roms/wiiu/Other Game/
└─ content/
   └─ CMCmn/
      └─ demo/
         └─ effect.szs           ->  category: demo

Scan either tree and read the files back (API or rom_files): the nested files carry a category that does not describe them.

Expected behavior The category describes what a file is to the user, so it should be anchored to the folder directly below the ROM's own root, with files nested deeper inheriting from it. Where several segments match, the outermost should win rather than whichever comes first in the enum.

Additional context The field is the natural thing for an API client to filter on — deciding what to download, what to show, what to skip. Today it cannot be trusted for files below the ROM root, and the miscategorisation is silent: the files simply appear under a tag they do not belong to.