fix(desktop): avoid updater-created Linux launchers

[darzi-admin]

Summary

• stop the headless hermes desktop --build-only self-update step from creating or rewriting Linux application launchers
• avoid persisting extensionless #!/usr/bin/env python3 source wrappers into Exec=
• preserve the absolute venv interpreter invocation path without dereferencing its symlink
• distinguish actual /usr/bin/env python* shebangs from hardcoded interpreter paths containing directory names such as /envs/
• preserve launcher registration for normal interactive Desktop launches
• add regression coverage for the updater, shebang classification, and unrelated-cwd venv import behavior

Why

Desktop self-update rebuilds through hermes desktop --build-only. Launcher registration previously ran before the build-only return, so the updater created a second hermes.desktop entry and could persist a repository source wrapper whose /usr/bin/env python3 resolves differently in a desktop session. The generated launcher then failed at startup when the desktop-session Python lacked Hermes dependencies.

The fallback must also retain venv/bin/python itself: resolving that symlink to the base interpreter discards the venv site-packages when launched from an unrelated working directory.

Test plan

• venv/bin/python -m pytest tests/hermes_cli/test_linux_desktop_entry.py tests/hermes_cli/test_gui_command.py tests/hermes_cli/test_relaunch.py -o 'addopts=' -q — 49 passed
• git diff --check -- hermes_cli/linux_desktop_entry.py hermes_cli/main.py tests/hermes_cli/test_linux_desktop_entry.py tests/hermes_cli/test_gui_command.py
• unrelated-cwd probe: unresolved venv interpreter imports hermes_cli; resolved base interpreter reproduces ModuleNotFoundError
• live local updater-equivalent check: hermes desktop --build-only completed successfully and did not recreate the removed duplicate launcher

[monerostar]

Ubuntu 26.04 on linux-5800x here. Live-checked this against current main.

Order bug on main: _register_linux_desktop_entry() still runs before the --build-only early return, so headless updater rebuilds rewrite ~/.local/share/applications/hermes.desktop. This tip returns on build_only first, then registers only on real launches. is_supported() is True on this box; desktop path resolves to ~/.local/share/applications/hermes.desktop.

Exec fallback matrix (forced resolve_hermes_bin=None, synthetic venv bin/python symlink to a base interpreter):

• main: Exec becomes the resolved base interpreter (.../base-python -m hermes_cli.main desktop)
• this PR: keeps .../venv/bin/python via os.path.abspath (does not drop pyvenv.cfg context)

Shebang helper on the PR tip:

• #!/usr/bin/env python3 wrapper -> True (falls back to interpreter path)
• hardcoded .../envs/foo/bin/python -> False (no false positive on directory name envs)
• #!/bin/sh -> False

When resolve_hermes_bin points at an env wrapper, PR Exec uses the abspath venv python module form, not the wrapper.

Focused tests on the PR tree:
pytest tests/hermes_cli/test_linux_desktop_entry.py tests/hermes_cli/test_gui_command.py -q -o addopts=
-> 33 passed in 0.77s

Note: GitHub currently reports no checks on branch fix/linux-desktop-updater-launcher from this host. Local Linux evidence above is green.

Related open Linux desktop-entry work (#80563, #80547, etc.) is mostly Exec rewrite / argv0. This one is the build-only registration skip plus the env-wrapper and venv-symlink pieces. Looks good.