Fix Linux AppImage startup on AMD systems

[monomyth]

Summary

Linux AppImages currently bundle libdrm_amdgpu from the build environment. On current Arch/Mesa AMD systems, Qt can load that copy before the host-matched library and abort during GLX probing with Could not initialize GLX even though the host's GLX renderer is healthy.

This change makes the generated and tracked AppRun launchers detect AMD DRM devices and preload /usr/lib/libdrm_amdgpu.so.1 when it is available. Non-AMD systems and systems without that host library keep the existing launch path unchanged. The environment-variable overrides exist only to make the launcher behavior testable without writing fake devices under /sys.

Verification

• Red: python3 -m unittest src.Tools.tests.test_linux_appimage_launcher failed because the launcher left LD_PRELOAD=existing.so
• Green: python3 -m unittest src.Tools.tests.test_linux_appimage_launcher src.Tools.tests.test_release_workflow passed all 6 tests
• On a MacBookPro13,3 running Omarchy Quattro f99d33a8, Linux 7.2.2-arch1-1-mbp133, Mesa 26.2.2, and Radeon Pro 460:
  • the released RC6 Build 1 AppImage reproduced the GLX abort without the preload
  • the same official AppImage remained running with the new launcher logic
  • Hyprland reported a mapped VibeCAD 26.3.1RC6 window
  • the process loaded /usr/lib/libdrm_amdgpu.so.1.134.0 and Mesa's libGLX_mesa.so, with the Radeon render node open
  • the kernel journal recorded no AMDGPU VM faults, ring timeouts, or resets

No UI layout or visual styling changes are included, so before/after images do not apply.

Compatibility

• Existing public functions and APIs are unchanged.
• No preference keys, tool names, or schema fields are renamed or removed.
• Non-AMD launch behavior is unchanged.
• Existing LD_PRELOAD entries are preserved after the host AMD library.