epic(desktop): restore release parity with the web app and keep it current

## Summary

Restore the Tauri desktop app as a current, continuously verified release channel for WorldMonitor, then keep it at defined parity with the web dashboard.

This is not a request for a native rewrite or pixel-for-pixel equivalence. The desktop app already reuses the SPA. Here, **parity** means that a user-visible capability shipped on the web is either:

1. working in the supported desktop build,
2. intentionally unavailable with a documented reason and usable fallback, or
3. tracked by a named blocker with an owner and validation path.

## Why now

Evidence captured from `origin/main` and GitHub on 2026-07-31:

- `package.json` and `src-tauri/tauri.conf.json` are at **2.10.0**.
- The newest published desktop release is **v2.5.23**, published from commit `e51058e17` on 2026-03-02.
- The last `Build Desktop App` run and the last standalone Linux runtime smoke run were both five months ago.
- The release workflow only runs on version tags or manual dispatch. The Linux runtime smoke is manual-only, so desktop regressions can reach `main` without an installed-app gate.
- The README currently labels the desktop binaries **Stable**.
- #5829 is a concrete user-visible symptom: the released macOS app lacks Internet Outages and Cyber Threats layers that are present in the current product.
- A high-priority Tauri security upgrade is still open in #5518, and Linux key storage remains open in #802 / #1905.

The shared frontend reduces implementation duplication, but it does not prove parity across the Tauri runtime, sidecar routing, permissions/keyring, authentication, packaging, updater, or platform webviews.

## Outcome

Ship a current, security-reviewed desktop release from a known `origin/main` SHA, prove its critical journeys on every supported platform, and add an automated contract that makes future desktop drift visible before the next release.

## Work plan

### 1. Establish the parity baseline

- [ ] Inventory user-visible web capabilities against the desktop runtime, including:
- panels and map layers;
- Full, Tech, Finance, Commodity, Energy, and Happy variant behavior;
- sign-in, account, billing, entitlements, and Pro/MCP gates;
- bootstrap/data loading, sidecar-local routes, and cloud fallback behavior;
- settings, API-key storage, local LLM providers, and cloud sync;
- live channels, external links, downloads, and update discovery;
- locale/RTL behavior and accessibility-critical keyboard flows.
- [ ] Classify each row as `parity`, `intentional difference`, `blocked`, or `not applicable`.
- [ ] For every intentional difference, document the user-facing fallback. Browser/PWA-only behavior should not be treated as a desktop defect when the distinction is deliberate.
- [ ] Turn confirmed gaps into small child issues rather than implementing the entire matrix in one PR.

### 2. Clear release blockers

- [ ] Reassess and land or replace the Tauri security upgrade in #5518 before publishing the next stable desktop build.
- [ ] Resolve Linux secret storage for environments without an activatable Secret Service (#802 / #1905), with a secure fallback and migration/cleanup coverage.
- [ ] Fix the released layer-selector drift reported in #5829 and add a behavior-level regression test.
- [ ] Reassess desktop readiness/error guidance in #1942 so local-vs-cloud failures are diagnosable.
- [ ] Audit the bundled Node runtime and Rust/Tauri dependencies; pin supported, patched versions deliberately and document any justified difference from repository CI.
- [ ] Verify that newly added API/server routes are either bundled into the sidecar, intentionally cloud-routed, or explicitly unsupported. No silent 404/502/503 parity gaps.

### 3. Restore a release train

- [ ] Build a release candidate from a recorded, current `origin/main` SHA after the blockers above are closed.
- [ ] Produce and launch-test the advertised artifacts:
- macOS Apple Silicon;
- macOS Intel;
- Windows x64;
- Linux x64 AppImage;
- Linux ARM64 AppImage.
- [ ] Verify signing/notarization status where applicable and make unsigned fallbacks explicit to users.
- [ ] Verify that an installed v2.5.23 app detects the new version and that `/api/version` plus `/api/download` resolve to the correct architecture/variant asset.
- [ ] Define the supported variant packaging model. If one World Monitor binary switches variants in-app while Tech has separate branding, make the workflow, updater, download endpoint, and README say the same thing.
- [ ] Publish release notes that summarize the parity delta since v2.5.23 and identify any remaining intentional differences.

### 4. Prevent parity drift

- [ ] Add a fast PR gate for desktop-coupled changes. At minimum, cover version consistency, Rust tests/checks, sidecar build/route coverage, Tauri capabilities, and desktop renderer bridges.
- [ ] Trigger that gate from relevant paths such as `src-tauri/**`, desktop runtime/bridge/updater code, sidecar builders, API routing, Tauri config, and desktop workflows.
- [ ] Add a scheduled current-`main` installed-app canary. A green build alone is insufficient: launch the packaged app, wait for sidecar readiness, and assert rendered content.
- [ ] Keep full cross-platform artifact tests on release candidates, with a smaller Linux smoke available on PRs or scheduled runs to control CI cost.
- [ ] Preserve screenshots and logs as CI artifacts on failure.
- [ ] Define a release freshness target (for example, no desktop-relevant change on `main` remains unreleased for more than 30 days) and surface breaches.

### 5. Prove representative user journeys

The release candidate must pass a recorded checklist on the supported platforms:

- [ ] cold launch renders non-blank dashboard content and reports sidecar readiness;
- [ ] bootstrap data loads and representative local/cloud API routes return usable data or an actionable configured-state message;
- [ ] current map layers are discoverable, including Internet Outages and Cyber Threats;
- [ ] switching supported variants yields the expected panels/layers after reload;
- [ ] sign-in, account/settings, billing handoff, and entitlement refresh work after the unified account work in #5901 lands;
- [ ] an API key can be securely saved, validated, reloaded, and removed;
- [ ] a local LLM configuration can be saved and exercised without leaking credentials;
- [ ] live channels and external URLs open through the intended trusted path;
- [ ] update discovery chooses the correct artifact for OS, architecture, and supported variant;
- [ ] one RTL locale and one non-English LTR locale complete the core flow without broken layout.

## Related work to incorporate, not duplicate

- #5829 — released desktop layer-selector drift
- #802 / #1905 — Linux keyring fallback
- #5518 — Tauri security upgrade
- #1942 — desktop readiness diagnostics
- #5757 — AppImage update metadata
- #5435 / #5487 — uninstall experience
- #5901 — unified account and billing surface shared by web and desktop

Each item should be revalidated against the current head before it is accepted; an old open PR is not automatically the correct fix.

## Acceptance criteria

- [ ] A maintained parity matrix exists and every non-parity row has an explicit decision or child issue.
- [ ] A new stable desktop release is published from a recorded current-main SHA with no unresolved release-blocking desktop security finding.
- [ ] All advertised artifacts install/launch, start the sidecar, and pass the representative smoke checklist.
- [ ] The v2.5.23 updater path leads users to the correct new artifact.
- [ ] Desktop-coupled changes have automated pre-release coverage, and a scheduled installed-app canary runs against current `main`.
- [ ] README/download/docs status reflects observed support rather than aspiration.
- [ ] Remaining web/desktop differences are intentional, documented, and visible to users.

## Out of scope

- Rewriting the shared SPA as native platform UI.
- Requiring browser-only/PWA/mobile behavior to exist unchanged on desktop.
- Folding every child fix into one giant PR.

Start with package.json and src-tauri/tauri.conf.json, then inspect the Build Desktop App release workflow and the manual Linux runtime smoke entry point. Use the current origin/main SHA and the listed related issues to establish the parity and release-blocker baseline. Done means the matrix, release artifacts, updater path, representative smoke checklist, and scheduled installed-app canary meet the stated acceptance criteria.

Written by the indexing model from the issue text.