fix(desktop): hydrate gateway registry from ProfileRail on mount

[FalconOrtiz]

Why

With a remote/SSH gateway as primary, cold boot painted only that gateway on the profile rail until the user opened Settings → Gateway. The registry already had every connection. The rail read `` but never loaded it, so fleet mode waited on another surface to publish the snapshot.

Scope

• ProfileRail calls refreshConnectionsRegistry() on mount when the registry atom is still null.
• Extends profile-rail-fleet.test.tsx for the null-registry hydrate path (Desktop: gateway list shows only the remote gateway until Settings → Gateway is opened and closed #101257).
• Adds the mock stub in profile-rail-connect.test.tsx.

Out of scope: main-process connect-on-demand deferral, boot-path hydration in use-gateway-boot, statusbar ConnectionSwitcher behavior.

Tradeoffs

Hydrate from the rail (smallest consumer fix) instead of gateway boot. Boot hydration would cover more readers; the rail is what users see broken, and the acceptance test targets that surface.

Blast Radius

Desktop profile rail only. Best-effort IPC connections.list; failures leave the prior single-gateway paint. No backend spawn for deferred local gateways.

Verification

cd apps/desktop npm run test:ui -- src/app/chat/sidebar/profile-rail-fleet.test.tsx src/app/chat/sidebar/profile-rail-connect.test.tsx

14 passed, exit 0.

Closes #101257

Made with Cursor

[Enough1122]

AI code review — automated review for reference; please use your judgment.

Overall: ProfileRail owns its initial connections-registry load on mount instead of waiting for Settings → Gateway or the statusbar switcher, fixing empty fleet rails on cold boot with an SSH/remote primary (#101257).

Correctness:

• apps/desktop/src/app/chat/sidebar/profile-switcher.tsx — one useEffect([]) that returns early when the registry is already published; failures swallowed (catch → undefined), registry stays null and existing fallbacks apply.
• Test mocks mirror the real store contract (refreshConnectionsRegistry publishes registry + multi-gateway flag); the new test asserts mount-time hydration and gateway-group order.

Non-blocking nit:

• Under React StrictMode double-mount the effect fires twice; refreshConnectionsRegistry should dedupe in flight (it does — inflight guard in the store) — just confirming the assumption holds.

Verdict: LGTM.

[FalconOrtiz]

Requesting squash-merge per engineer agreement (2026-09-04): AI-review merge-ready pack; nits non-blocking; no rewrites.

This PR is in the agreed pack with #101523 #101528 #101529 #101530 #101531 #101537 #101544 #101547 #101548 #101549 #101551.

Out of pack (do not block this merge): #101564, #101796/#101091, #101318.