fix(desktop): keep healthy gateways usable when primary sign-in expires

[ctaylor86]

What does this PR do?

An expired login on the saved primary gateway can put “Hermes couldn't start” over the entire Desktop window even after the user has selected a healthy local gateway. The local backend still answers requests, but the overlay prevents opening Settings or using the foreground workspace.

This change keeps post-startup authentication recovery attached to the affected primary. An already-open healthy secondary remains usable; returning to the affected primary still shows its sign-in recovery. Genuine initial-startup failures are unchanged.

Why it matters / suggested P2: this is failure isolation for supported multi-gateway use, not a cosmetic error-message change. Recovering the expired primary login is the existing escape; it should not be a prerequisite for using another working gateway.

Related Issue

Related to #90149. #105139 and #102673 address connection switching/readiness and profile caches; neither changes these boot-error presentation paths. This PR is independently mergeable and does not replace those contributions.

Type of Change

• 🐛 Bug fix (non-breaking change that fixes an issue)
• ✨ New feature (non-breaking change that adds functionality)
• 🔒 Security fix
• 📝 Documentation update
• ✅ Tests (adding or improving test coverage)
• ♻️ Refactor (no behavior change)
• 🎯 New skill (bundled or hub)

Changes Made

• apps/desktop/src/app/gateway/hooks/use-gateway-boot.ts: scope reconnect errors, progress events and delayed boot snapshots; preserve/restore primary recovery when foreground ownership changes.
• apps/desktop/src/app/gateway/hooks/use-gateway-boot.test.tsx: reproduce the blocked healthy-secondary case and retain ordinary-outage/primary-recovery controls.

How to Test

1. Connect Desktop to a remote primary, then select a healthy local gateway.
2. Make the primary's WebSocket-ticket refresh fail with confirmed authentication expiry (401/403), while the local backend remains responsive.
3. Before: the global startup-error overlay intercepts Settings. After: local Settings opens; selecting the affected primary retains sign-in recovery.

Run against head a8e46c6358bd4d34bcc61ee35908c49cbe8dc6a7:

cd apps/desktop
npx --no-install vitest run src/app/gateway/hooks/use-gateway-boot.test.tsx src/components/boot-failure-reauth.test.ts
npm run typecheck

Published-head focused verification: 72 tests / 2 files passed, plus all three Desktop TypeScript projects.

Additional isolated Electron evidence used the real renderer, preload, IPC, managed-local spawning and backend requests with a synthetic remote-auth facade: baseline 401 and 403 cases each failed the shell/Settings assertions while local ping succeeded; the unchanged reviewed fix passed 7/7 checks in each case. Refusal and blackhole controls passed 17/17 each. The named checks cover: boot and hidden-window isolation; observing the actual ticket rejection; a successful managed-local ping; no foreground-blocking overlay; opening local Settings; and clean hidden-window completion. This is not a claim of testing the real hosted Cloud/OAuth service.

Checklist

Code

• I've read the Contributing Guide
• My commit messages follow Conventional Commits (fix(scope):, feat(scope):, etc.)
• I searched for existing PRs to make sure this isn't a duplicate
• My PR contains only changes related to this fix/feature (no unrelated commits)
• I've run pytest tests/ -q and all tests pass
• I've added tests for my changes (required for bug fixes, strongly encouraged for features)
• I've tested on my platform: macOS; platform-independent renderer logic, no new native APIs

Documentation & Housekeeping

• I've updated relevant documentation (README, docs/, docstrings) — or N/A (inline behavior comments updated; no new setup required)
• I've updated cli-config.yaml.example if I added/changed config keys — or N/A
• I've updated CONTRIBUTING.md or AGENTS.md if I changed architecture or workflows — or N/A
• I've considered cross-platform impact (Windows, macOS) per the compatibility guide — or N/A
• I've updated tool descriptions/schemas if I changed tool behavior — or N/A

Screenshots / Logs

The regressions above were run against the baseline and the reviewed fix. git diff --check and the public-data/secret scan passed. Independent code review and isolated UI review were completed before publication. Private workspace screenshots are intentionally omitted; no user data or configuration is included.

No new dependencies, configuration keys or model-tool schemas. No Python source changes; the full Python suite was not run and its checklist item remains unchecked. macOS was executed; Windows/Linux were considered but not run locally. Live CI results are available in the PR checks rather than frozen here.