gui: Fix randomly untranslated game list categories

[mariobob]

Resolves #17632

What was happening

Localized is a QObject whose members are initialized from tr() calls, so constructing one issues roughly forty QObject::tr() lookups. game_list_frame::OnParsingFinished() was constructing one inside the add_game lambda, and add_game runs on the QtConcurrent::map workers that scan the game list. Every game entry therefore fired its own batch of tr() calls, in parallel with every other entry being scanned at the same time.

Concurrent translator lookups race, and a losing lookup falls back to returning the untranslated source string. That is exactly the reported symptom: with a non-English UI language, a random subset of rows shows the English category name (Disc Game, HDD Game, ...), and which rows are affected changes on every refresh. The same Localized instance also backed the dev_flash title lookup, so VSH entry names were exposed to the same race.

The fix

Construct Localized once on the UI thread in OnParsingFinished() and hand the workers a std::shared_ptr<const Localized> to read from. The workers now only do const map lookups against already-translated strings, so there is nothing left to race.

As a side effect this removes ~40 tr() calls and several std::map constructions per game entry from the scan path, which is a measurable win on large libraries (previously a 500-game library built the entire localization table 500 times).

Testing steps

1. Set the RPCS3 UI language to a non-English one that has translations for the game list categories.
2. Press Refresh on the game list repeatedly.
3. The Category column stays fully translated on every refresh. Before the change, entries flipped between the translated name and the English source string at random.

Worth exercising on a reasonably large library, since the race is easier to hit the more entries are scanned in parallel.

[Megamouse]

While this is a good change and fixes the issue, it does not actually "fix" what's happening.
There shouldn't be a race condition here in the first place, so this is still a bug in Qt.

[Megamouse]

I'll take the chance and comment on what I think is undisclosed AI usage.

The author presents a large amount of detailed information that is obvious to anyone who has the slightest understanding of the code, in a language that suggests that it was not written by a human.

They mention a "measurable win on large libraries" but don't show any real world numbers.

A race condition on our side is suggested when the test methodology shows that there should in fact not be a data race at all, since the language is static.
As said before, this is an upstream regression in Qt 6.10 and should not exist in the first place.