Pre-defined Steam launch options: picker menu

[Leb-Sun]

Games with multiple Steam launch entries (Play DX11 / DX12, safe mode, mod
launcher…) always booted the default one. This adds a "Launch Options" item to
the STEAM dropdown on both game screens — only shown when the game actually has
2+ entries — opening a Workshop-style picker (WsBg scheme, pane-nav wired).
Tapping a row saves it as the game's default.

The selection is explicit per-shortcut state (launch_option_exe /
launch_option_args extras): an untouched shortcut shows the default entry as
active, a manual exe change in shortcut settings turns options off entirely, and
a read-only hint under Exec args shows the args the active option appends.
LaunchInfo gains arguments / launchId parsed from appinfo config.launch, and
stale cached rows heal via a one-shot PICS re-fetch when the picker opens. The
picker and the game-screen launch resolve the shortcut through one shared
resolver over the loaded container list, so the pick and the launch always
resolve to the same shortcut.

At launch the selection goes through Steam natively. The Android side resolves
the picked entry's config.launch key and passes it to the in-Wine launcher as
WN_STEAM_LAUNCH_OPTION; the launcher hands it to IClientAppManager::LaunchApp
so Steam launches that entry with its own args. Custom launch args are written to
the game's localconfig.vdf LaunchOptions (env vars stripped — those go through
the container env), and Steam appends that value to the game's command line
itself, as it does on desktop. Env vars keep flowing through the container env.
Both launch paths deliver the args: on the LaunchApp path Steam appends
localconfig itself; when an unready appinfo forces the launcher's CreateProcess
fallback, it launches the game with the same picked-entry + custom args on argv
(previously the fallback dropped them), and skips the fallback if a slow LaunchApp
spawn turns up late, so a late spawn isn't started twice.

Verified on device on the Steam Launcher path across repeated back-to-back
launches, arg changes and game switching, on both the LaunchApp and
CreateProcess-fallback paths, with DXVK_HUD=fps alongside the game args: the
picked entry's own args and the user's custom args arrive together on the game's
command line — checked against the running process, not inferred — and the env
vars apply through the container env. Adds store_game_launch_options,
store_game_launch_option_failed, store_game_launch_options_count and
shortcut_launch_option_args in all locales.

Two known edges, both independent of the picker. Steam's appinfo is frequently
not ready on the first LaunchApp attempt, so the launcher re-primes it and
retries, and falls back to CreateProcess if the app still doesn't spawn; the
fallback carries the same args, and appinfo readiness is a Steam/container-state
matter upstream of this feature. And because a selection is matched by executable
plus arguments, a game listing two entries that agree on both resolves to the
first — they launch identically, but a per-entry detail like a beta key would
come from the wrong one.

[Xnick417x]

Is this ready for testing? I see conflicts

[Leb-Sun]

Is this ready for testing? I see conflicts

This is now ready for testing env vars still require %command%, for example DXVK_HUD=fps %command% -windowed