chore(desktop): audit and deliberately pin the bundled Node runtime (22.14.0 vs CI Node 24)

## Summary

The desktop sidecar ships Node **22.14.0** (`scripts/download-node.sh:7`, `.github/workflows/build-desktop.yml:118`) while every CI job — including the desktop build and the Linux canary themselves — validates against Node **24** (`build-desktop.yml:78`, `test-linux-app.yml:25`, `test.yml`). The shipped runtime is two majors behind the tested one, and 22.14.0 predates a long line of 22.x security releases.

`scripts/download-node.sh` verifies SHA256 against `SHASUMS256.txt` fetched from the same origin as the archive, and never verifies the GPG signature (`SHASUMS256.txt.sig` is not fetched) — protection against corruption, not a compromised dist host.

## Ask

- Pick and pin a supported, patched runtime deliberately; document any justified difference from repo CI (#5902 §2 explicitly requires this audit).
- Align the CI validation matrix with the shipped major (or vice versa) so tests exercise what users run.
- Consider GPG signature verification for the dist download.

Found during the #5902 parity baseline audit (see `docs/desktop-parity-matrix.md`). Part of #5902.

Start with scripts/download-node.sh and the referenced sections of .github/workflows/build-desktop.yml, test-linux-app.yml, and test.yml; compare the shipped Node 22.14.0 with the CI Node 24 validation. Review docs/desktop-parity-matrix.md and #5902 for the audit context. Done means the runtime choice is pinned and documented, CI validates the shipped major, and the GPG verification consideration is addressed.

Written by the indexing model from the issue text.