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 persists on the shortcut (launch_exe_path + new
launch_exe_args extra) and the entry's args ride the existing
SteamLaunchOptions %command% pipeline from #520: env prefix stays on the env
path, selected args expand at %command%, user args after it follow, join-connect
still appends last. Covers ColdClient, Goldberg and the Steam Launcher;
localconfig LaunchOptions / setLaunchCommandLine keep getting the raw spliced
template as before, and the steam-env stamp now includes the effective line so
switching options re-runs the localconfig edit.

Also fixes the Steam Launcher dropping game args in direct-exe mode:
wn-steam-launcher read only argv[1] and CreateProcess'd the bare exe, so
anything after the game path never reached the game. It now forwards argv[2..]
(steam.exe asset rebuilt from source). Verified on device on both the ColdClient
and Steam Launcher paths.

LaunchInfo gains an arguments field parsed from appinfo config.launch (stale
cached rows heal via a one-shot PICS re-fetch). A selection routes through
Steam's LaunchApp using the entry's config.launch index (see the follow-up
comment below), so Steam launches and registers the picked entry itself. Adds
store_game_launch_options, store_game_launch_option_failed and
store_game_launch_options_count in all locales.

Review + testing hardening: the direct-exe override now compares the full relative
path (entries differing only by directory were silently ignored) and re-selecting
Steam's default entry clears the args override so launches return to LaunchApp. The
picker's selection is explicit state (launch_option_exe/launch_option_args
extras): untouched shortcuts show the default entry as active, a manual exe change
in shortcut settings turns options off entirely (a custom exe is never adopted as a
launch option), and a read-only hint under Exec args shows the args an active option
appends (new string in all locales). The picker re-reads state on every open, both
game screens share one state holder, and saving a selection no longer loads every
shortcut's icon. The launcher re-quotes forwarded args per CommandLineToArgvW rules,
drops whole args with a logged warning instead of cutting mid-token, and no longer
logs raw command lines (execArgs can carry credentials). The on-disk option filter
matches case-insensitively, like the launch path resolves those same paths. The
family-shared flag is per-process native state like the pushed command line, so
warm (stamp-hit) launches now re-push both instead of only the command line.

[Leb-Sun]

Follow-up: launch options now drive Steam's LaunchApp with the picked entry's launch-option index, replacing the direct-exe path.

On-device testing surfaced a bug in the direct-exe approach from this PR: it works only once per container. The direct-exe game relies on SteamAPI_Init re-attaching to the Steam session via the inherited env; on relaunch that fails (connect to global user failed) from the cached-credentials login, so MCC (-no-eac) / GTA5 (-scOfflineOnly) launch once, then need a container recreate. Wine logs showed an identical launch both times, failing only on the second. Driving IClientAppManager::LaunchApp with the entry's config.launch index instead makes steamclient launch the picked entry itself (Game process added), which survives repeated exit/relaunch.

The launcher (main.cpp) now reads WN_STEAM_LAUNCH_OPTION and passes it as uLaunchOption (unset → 0, unchanged). The Android side resolves the index from the picked entry, falling back to the resolved exe so custom args / a cleared picker still route correctly. Direct-exe stays only for an overridden exe that isn't a config.launch entry (the redprelauncher/W^X case), and main.cpp still falls back to CreateProcess if LaunchApp can't bring the game up. Steam Launcher path only — ColdClient/Goldberg untouched.

Scope note: this changes the launch mechanism, not just the picker UI — any Steam game whose resolved exe matches an appinfo entry now launches via LaunchApp rather than direct-exe. It supersedes the "a selection with args forces direct-exe" behavior from the earlier commits here (that was the source of the once-per-container bug). Happy to split it into its own PR if you'd rather keep #600 to the picker.