[Bug][Linux/AppImage] External HTTPS links are handed to GNOME as percent-encoded URIs

**Describe the bug**

Buzz Desktop v0.5.2 installed from the official Linux AppImage cannot open the Builderlab authentication link during community onboarding. The app generates a valid HTTPS URL, but the packaged external-open chain hands GNOME the entire URL percent-encoded (`https%3A%2F%2F...`). GNOME then shows “No Apps Available”, blocking sign-in.

This is specific to the AppImage launch environment. Fedora's normal HTTP/HTTPS XDG association is healthy, and `/usr/bin/xdg-open https://example.com` opens Brave normally.

**Steps to reproduce**
1. Run the official unchanged Buzz Desktop v0.5.2 amd64 AppImage on Fedora Workstation 44 with GNOME.
2. Start first-community onboarding and choose the hosted community path.
3. Select **Sign in to continue**.
4. Observe GNOME display “No Apps Available” instead of opening the browser.

The generated URL begins with `https://app.builderlab.xyz/api/goose/v1/auth/login?...`. Query values are intentionally omitted because they contain temporary callback state.

**Expected behavior**

External HTTP(S) URLs should be passed unchanged to the host desktop opener and open in the configured browser. macOS and Windows behavior should remain unchanged.

**Version and platform**
- Buzz version: 0.5.2
- Package: official amd64 AppImage, unchanged checksum
- OS: Fedora Workstation 44 x86_64
- Desktop: GNOME
- Configured browser: Brave

**Logs / additional context**

The source path is `start_builderlab_login` in `desktop/src-tauri/src/builderlab.rs`: `login_url()` builds a valid `url::Url`, then `app.opener().open_url(login_url.as_str(), ...)` delegates through `tauri-plugin-opener` / the `open` crate to `xdg-open`.

The AppImage supplies its own `usr/bin/xdg-open` through the AppRun `PATH`, and opener children inherit AppImage GLib/GIO environment variables. A Buzz-scoped diagnostic wrapper that delegated to the host `/usr/bin/xdg-open`, removed AppImage GLib/GIO variables, and decoded only an already fully encoded HTTP(S) URI made sign-in work. This indicates the fault is at the packaged Linux external-open boundary rather than URL generation or the desktop HTTP association.

A portable fix should make AppImage external URL launches use a clean host opener environment for generic HTTP(S) links rather than special-casing Builderlab. I am willing to submit a focused fix with regression coverage.

Start at start_builderlab_login and login_url() in desktop/src-tauri/src/builderlab.rs, then trace app.opener() through tauri-plugin-opener, the open crate, and the AppImage AppRun environment. Compare the packaged and host xdg-open paths and inherited GLib/GIO variables. Done means generic HTTP(S) URLs open unchanged from the AppImage on Fedora GNOME, with regression coverage and macOS/Windows behavior preserved.

Written by the indexing model from the issue text.