fix: telemetry flush-on-exit panic and broaden Linux EGL/render fallback

[devlint]

Summary

A single-looking crash report on #135 turned out to be two independent bugs:

1. Telemetry flush-on-exit panic (cross-platform, not Linux-specific) — the vendored tauri-plugin-aptabase fork's flush_blocking() used futures::executor::block_on, which provides no Tokio reactor context. It fires unconditionally from the plugin's RunEvent::Exit handler on the main thread, so any process exit within 60s of launch (any OS, any reason) — before the background 60s flush had drained the queued launch telemetry event — panicked with there is no reactor running, must be called from the context of a Tokio 1.x runtime. This is the exact panic text reported on Linux, but it has nothing to do with Linux or EGL: it just gets exposed reliably there because EGL failures cause near-instant exits.
   • Fixed at the source: pushed a one-line fix to the fork (devlint/tauri-plugin-aptabase@364eb00, branch fix/tokio-runtime-panic) swapping futures::executor::block_on for tauri::async_runtime::block_on — the same pattern already used to fix the sibling start_polling() call in the same file. Bumped the pinned rev in Cargo.toml/Cargo.lock accordingly.
2. Linux EGL/render fallback was under-covered — the existing WEBKIT_DISABLE_COMPOSITING_MODE/WEBKIT_DISABLE_DMABUF_RENDERER (added for GitWand starts and displays a blank window only! #135/Cannot open the App | deb | Linux Mint 22 x86_64 #139 in v3.6.1) only steer WebKitGTK's compositing path, not the earlier EGL display acquisition step, which is where Could not create default EGL display: EGL_BAD_PARAMETER can originate on some native-Wayland/Gnome setups. Added LIBGL_ALWAYS_SOFTWARE=1 alongside the existing two vars, guarded so it never overrides a value already set in the environment.

Design doc: docs/superpowers/specs/2026-08-11-issue-135-linux-startup-robustness-design.md
Plan doc: docs/superpowers/specs/2026-08-11-issue-135-linux-startup-robustness-plan.md

Addresses #135.

Test plan

• Component 1 — verified with a real before/after test on macOS: launched the currently-installed v3.6.1 release build, quit it gracefully (AppleEvent quit, not kill — a plain signal doesn't trigger Tauri's RunEvent::Exit) within 3s of launch → reproduced the exact reported panic verbatim in the terminal. Rebuilt with the fix (pnpm tauri build) and repeated the identical test → clean exit, no panic.
• cargo check passes; git diff --stat for the rev bump touches only Cargo.toml + Cargo.lock's tauri-plugin-aptabase entry (no unrelated dependency churn).
• Component 2 is unverified against the actual reporting environment (Fedora 44 / Gnome / AppImage) — there is no Linux GPU/EGL harness available in CI or locally. It ships as a broader fallback; needs a report-back from affected users, the same loop that confirmed the original v3.6.1 fix worked for the first reporter.
• Note: the Rust backend is not compiled by PR CI (ci.yml gates the desktop job to pushes on main), so this Linux-only code path gets its first real CI compile after merge.

Follow-up (documented, not in this PR)

The AppImage LD_LIBRARY_PATH-pollution theory (AppImage's AppRun wrapper could cause GitWand's own process to resolve GTK/WebKit/EGL against bundled, version-mismatched libraries) remains open. Properly fixing it requires a self-re-exec early in main(), which is riskier and deserves its own design — see the design doc's Follow-up section. Next concrete step: ask the reporter to run ldd against their extracted AppImage binary to confirm or rule this out.