fix: preserve Proton's S: gamedrive mapping when launching TeamSpeak

[gitshipdone]

Problem

Launching TeamSpeak through Arma3Helper.sh deletes the S: drive mapping from the Arma prefix on Proton builds that enable the gamedrive option (current Proton Hotfix does by default).

The script exports STEAM_COMPAT_DATA_PATH but not STEAM_COMPAT_INSTALL_PATH / STEAM_COMPAT_LIBRARY_PATHS, and then invokes the full proton run verb. Proton's gamedrive setup needs both variables to resolve the game's Steam library (see try_get_game_library_dir() — proton, proton_11.0 branch, the check is at ~line 275 in the shipped Proton Hotfix script). When either is missing it returns None and setup_dir_drive() removes pfx/dosdevices/s: from the live prefix.

Symptom this causes

Arma keeps running on already-open file handles, but multiplayer signature verification (verifySignatures = 2 servers) re-opens PBOs on demand. Every file Arma loads through S: then fails the check, producing kicks like:

Files "dta\bin.pbo" are not signed by a key accepted by this server.
Player X: Wrong signature for file S:\workshop\content\107410\<id>\addons\<name>.pbo

naming a different, provably-clean file each join — but only while TeamSpeak is running. This is extremely confusing to debug from the game side (files validate, keys match, network is clean). Forensics that pinned it: the prefix's dosdevices/ mtime matches the helper launch to the second, and across many kicks every flagged file was S:-pathed while Z:-pathed workshop mods never appeared once.

Fix

Derive both variables from COMPAT_DATA_PATH, which always lives in the same Steam library as the game:

• runs only when the user hasn't already exported either variable (the config file is sourced earlier and can still override),
• canonicalizes with readlink -f first, and only exports when the derived <library>/common/Arma 3 directory actually exists — a noncanonical/symlinked COMPAT_DATA_PATH can never point Proton at a wrong library,
• otherwise prints a warning telling the user to set both variables in their config, and changes nothing.

Verified

Reproduced and fixed on Arch, Arma 3 2.20 + Proton Hotfix (Wine 11), TS3 + ACRE2 in the shared prefix: with the exports, s: survives the TeamSpeak launch (watched dosdevices/ live), the ACRE game pipe still connects, and joins to a verifySignatures=2 server pass cleanly with TS connected. shellcheck clean (zero findings before and after), bash -n passes, both derivation branches exercised (default-library path and custom-library path derive correctly; bogus path falls through to the warning).