[thcp]

Three fixes to the desktop in-app updater and app-root lookup (Windows and Linux updater; the app-root change applies to every desktop build). All in desktop/src-tauri/src/main.rs.

What changes for the user

• A failed update no longer leaves the app without its backend. The swap renames backend/ to backend.old, then the new backend/ into place, then swaps the exe. If any of those renames fails (for example a virus scanner holding a handle), the renames already done are now undone, newest first, so the previous install is left exactly as it was. Before, a failure on the second rename left no backend/ at all, and the next launch's cleanup deleted backend.old, the only copy, so the install needed a full re-download.
• The launch cleanup keeps backend.old when there is no backend/app. Then it is the only copy of the app (a swap that stopped between its renames, for example a power cut), so it is left on disk instead of deleted.
• The rename retry budget is about 5 s instead of 1.5 s, so a slower scan of the freshly extracted backend does not fail the update. A missing path is not retried, because it never clears by waiting and the update command runs on the window's thread.
• Updates are accepted only from this repository's releases. The update URL check allowed any github.com path, so a script in the page could hand the updater a release archive from another repository, together with that repository's own checksum. It now requires https://github.com/stemdeckapp/stemdeck/releases/download/. The two small files read before an update (runtime-version.json and the .sha256 that the archive is checked against) now go through the same check; before, they had no check at all. objects.githubusercontent.com is no longer accepted as a starting URL: the frontend always passes the releases API's browser_download_url (verified against the v0.20.0 and v0.19.1 asset lists), and GitHub's redirect to its asset host is followed by the HTTP client, not by this check.
• A release build no longer takes its app root from the working directory. A portable StemDeck.exe started from a terminal inside a source checkout ran that checkout's app/ instead of its own install. Only debug builds (cargo tauri dev) look at the working directory now. A release build inside the repo's target/ still finds the checkout through the exe's own path, as before.

How it was verified

• Red then green: five Rust unit tests, each failing on origin/big-release for the stated reason and passing with the change:
  • the_launch_sweep_keeps_backend_old_when_it_is_the_only_backend (before: backend.old/app deleted)
  • a_failed_backend_install_puts_the_previous_backend_back (before: backend/ missing after the failed rename)
  • only_our_own_release_assets_are_downloadable_as_updates, extended with another repository, a lookalike repo name, a dot-segment path, a non-release path of this repo and an asset-host URL (before: https://github.com/someone/stemdeck/releases/download/v1/x.zip accepted)
  • update_checksum_and_runtime_id_fetches_are_held_to_the_same_urls (before: the small-file fetch went to the network)
  • only_debug_builds_take_the_app_root_from_the_working_directory (before: the checkout was returned with the release flag)
• Added after review: a_failed_exe_install_puts_the_previous_backend_and_exe_back (a failure at the last rename undoes all four renames).
• cargo fmt --check, cargo clippy --tests -- -D warnings and cargo test (205 passed) pass on Windows. The Linux and macOS compile is left to the PR's Rust check jobs (no platform-only block was changed).
• Independent Rust and security reviews of the diff.

Update path

• This changes the shell binary. It does not touch uv.lock, so the runtime id is unchanged.
• The updater code that runs is the one in the installed build, so these fixes protect the updates that start from a build containing this change, not the update to it.

Known gaps, not changed here

• After a failed and rolled-back update the files on disk are intact, but the backend was already stopped and is not restarted, so the window needs an app restart. This was already the case before.
• download_app_update still takes the expected checksum from the page, so a script in the page could install an older release of this repository. It can no longer point at another repository.

What to verify by hand on an installed build

1. Real release URLs still pass (Windows portable, and Linux if available). Install a portable build made from this change in a user-writable folder, then let it check for an update against a newer published release. Expected: either the in-app update is offered, or the dialog shows the full-download note for changed Python dependencies. Not expected: an error containing refusing to download an update from. The DevTools console line [catalog] in-app update unavailable: shows the exact reason.
2. If an in-app update is offered, apply it. Expected: the app restarts on the new version, and on the launch after that backend.old and StemDeck.exe.old are gone from the install folder.
3. Working directory is ignored. Open a terminal, cd into a StemDeck source checkout, and start the installed StemDeck.exe by its full path. Expected: it opens the installed app with its own settings and library location, not the checkout.
4. A forced failure of the backend rename (a handle held by a scanner) cannot be set up reliably by hand; the unit test covers the rollback on a temp folder.