fix(desktop): keep Settings stable during Runtime Host refresh

[chihumyum]

Summary

• Keep last-ready masked Settings snapshots in renderer memory so reopening Settings does not flash a warning or collapse Runtime Host-owned rows during revalidation.
• Separate Runtime Host catalog, settings, connections, and mutation authority so stale reads or writes cannot cross Host epochs.
• Keep Desktop-owned preferences available while Host-owned controls remain visible but inert until the current Runtime Host is verified.
• Preserve error and unavailable feedback without changing IPC contracts or persistent storage.

Behaviour

Before fixing, the yellow banner flashes each time the settings page is opened.

before.mp4

After fixing, no yellow banner was ever shown.

after.mp4

Verification

• npm run lint
• npm run format:check
• npm run build
• npm run typecheck
• npm --workspace @maka/desktop test — 1050/1050 passed
• npm --workspace @maka/desktop run build-storybook
• npm --workspace @maka/desktop run smoke:storybook — 168/168 passed
• npx knip --workspace apps/desktop
• npx knip --workspace packages/ui
• npm run astryx:surface-inventory
• npx playwright test --config e2e/playwright.config.ts e2e/settings.spec.ts — 3/3 passed

Full desktop E2E completed with 39 passed and 1 skipped. One unrelated
prompt-rail.spec.ts geometry assertion remained intermittent at exactly
24px versus <24px; this PR does not modify that surface, and an isolated
three-run repeat passed twice.

Review focus

• Runtime Host epoch changes and stale read/write fencing
• masked snapshot caching and secret lifetime
• mixed ownership boundaries on General, Projects, and Data

AI use

Select exactly one:

• No generative tool made a substantive contribution
• Generative tooling made a substantive contribution

Tool(s) and scope: Codex — implementation, race analysis, unit/Storybook/Electron
E2E coverage, regression verification, and pull request preparation. The human
contributor reviewed the contribution and accepts responsibility for it.

Checklist

• Tests cover the change and fail without it
• Lint, format, typecheck and the affected suites pass locally

Does this PR entail a change in behavior?

• Yes — described under Summary above
• No

[jackwener]

Automated review of exact head 54651d6b0aeca844f527f75cfe00f4a8d6b6c9fc against current main@d62857a8357e9160926726a2a13096bc2dc2b91d.

The defect remains on main: every Settings mount starts the Runtime Host catalog/settings/connections resources cold, so the mixed-ownership General page briefly renders defaults/loading feedback before Host data arrives. The patch keeps only masked read snapshots in renderer memory, keys Host data by profileId:hostId, prunes an old epoch when the catalog changes, and keeps cached Host controls inert until the current mount verifies the target. The separate read/write tickets also prevent a late old-Host result from populating the newly selected Host. The reopen E2E observes the transient DOM, so it would catch the original flash rather than only asserting the settled page. I found no actionable P0-P2 defect; git diff --check is clean.

Required conclusions:

1. Optimal for the actual problem: yes. The implementation is larger than the symptom, but stable cross-unmount rendering requires a cache, and the masking, epoch key, verification bit, and interaction fence are necessary to avoid turning stale UI into write authority.
2. Production code to delete: the PR replaces the older parallel resource unions/ticket refs; none further identified.
3. Tests to delete/replace: none identified. The helper tests and transient-DOM E2E cover distinct contracts.
4. Deeper refactor: no; keeping the cache outside AppShell avoids lifting Settings-only state into a broader owner.
5. Ready to merge: not yet. No hosted test check is reported on this exact head, and automated review is not approval.
6. Residual risks/gaps: this changes user-visible loading/error behavior and the security-sensitive Host write boundary across General, Projects, and Data. The supplied tests cover cache epochs and the default General reopen, but independent human review should still exercise non-default Host selection and failure/retry behavior.

This affects user-visible behavior and Runtime Host authority fencing, so CONTRIBUTING.md requires independent human judgment on the exact head.