fix(desktop): adopt saved primary profile before gateway boot

[weddle]

What does this PR do?

Fixes a race at cold boot in the desktop app. The renderer connects the primary gateway before it reads which profile the desktop persisted, so fetches keyed on gatewayReady can run while $activeGatewayProfile still holds its initial 'default'.

I measured the order on unpatched main with atlas as the persisted profile. desktop.profile.get() runs once, after getConnection() has already resolved. At the moment the connection is obtained the atom reads "default". The shared gateway client publishes setState('open') inside connect() before the promise resolves (apps/shared/src/json-rpc-gateway.ts), and boot awaits adoptPrimaryProfile() later. The sidebar's first sessions and projects fetches race the adoption IPC and lose. Any machine whose primary profile is a named one paints its first sidebar under the wrong profile.

PR #50529 identified this ordering problem. Its review asked for a rebase onto the current adoptPrimaryProfile() helper with the seed applied before cold-boot getConnection(). This PR implements that shape, with credit to #50529's author.

1. Read before connect. The IPC read of the persisted profile moves out of adoptPrimaryProfile() into readPrimaryProfile() and applyPrimaryProfile(). Cold boot applies it to the atom, to the registry's primaryProfile, and to event tagging before desktop.getConnection(). HMR-survivor adoption keeps its path, as does the catch that falls back to 'default'.
2. Align the registry's active pointer during adoption. applyPrimaryProfile() also runs the primary fast path of ensureGatewayForProfile(), a synchronous setActive that is safe before connect. Skipping this step drops the open transition: state events tagged with the adopted primary fail the activeKey comparison in reportGatewayState and the UI sits at "connecting" forever. A test guards this.

If the preferred path is updating #50529 itself, the tests here can move there.

Related Issue

Addresses the boot-ordering defect tracked in PR #50529's review: adopt the persisted primary profile before getConnection(). In-flight work on the same hook covers different lifecycle paths: #74552 handles reconnect after sleep, #74388 gates session restore. I am glad to coordinate rebases with either.

Type of Change

• Bug fix (non-breaking change that fixes an issue)

Changes Made

• apps/desktop/src/app/gateway/hooks/use-gateway-boot.ts: split the read of the persisted profile from applying it. startBoot() reads and applies before getConnection(). setPrimaryGateway waits until the profile is known. Event tagging uses the adopted profile. applyPrimaryProfile() aligns the registry's active pointer.
• apps/desktop/src/app/gateway/hooks/use-gateway-boot.test.tsx: an ordering test (the persisted atlas must be applied before getConnection(), and the profile IPC must precede the connection IPC) plus an open-state test (after the socket opens on a named-primary boot, $gatewayState must publish 'open').

How to Test

1. cd apps/desktop && npx vitest run --project ui src/app/gateway/hooks/use-gateway-boot.test.tsx passes 7 tests.
2. Red-on-old for the ordering test: overlay only the test file onto main and run it. One test fails, six pass. The mocked getConnection asserts the atom already carries the persisted profile; on old code adoption runs after connect, so the assertion rejects inside getConnection. The runner reports expected "vi.fn()" to be called once, but got 0 times on profileGet, the downstream trace of that rejection.
3. The open-state test passes on old main by construction. It exists to guard the hazard described in change 2. I verified it by mutation: the fix with the ensureGatewayForProfile() line deleted fails it with expected 'idle' to be 'open'.
4. Manual: put a named profile in the desktop's active-profile.json, cold-launch, and confirm the first sidebar population belongs to that profile and the app reaches "open".

Checklist

Code

• I have read CONTRIBUTING.md
• My commit messages follow Conventional Commits
• I searched existing PRs for duplicates (fix(desktop): seed saved profile before gateway boot #50529 discussed above; fix(apps): stop Desktop sleep/wake from wiring primary chat to the wrong profile backend #74552, fix(desktop): settle the gateway connect on gateway.ready and keep a stale boot from finishing after a switch #73821, and fix(desktop): gate session restore on profile initialization #74388 reviewed for overlap)
• This PR contains only related changes
• Full desktop vitest run on Node 22, matching CI: ui project 354 files, 3,134 tests, 0 failed; electron project 867 passed, 0 failed. Local note: Node 26 produces roughly 200 spurious jsdom localStorage failures on unmodified main, so a clean local run needs CI's pinned Node 22.
• I added tests that fail without this change (the ordering test; the open-state test is mutation-verified as described)
• Tested on: macOS 15 (arm64, Apple M4), Node 22.23.2

Documentation & Housekeeping

• Docs: N/A (bug fix, no user-facing surface change)
• cli-config.yaml.example: N/A
• CONTRIBUTING/AGENTS: N/A
• Cross-platform: renderer and Electron TypeScript only, no platform-specific code paths
• Tool descriptions/schemas: N/A

Screenshots / Logs

Instrumented boot on unpatched main, persisted primary atlas:

profileAtGetConnection = "default"    (atom still at initial value when the connection is obtained)
profileGetCalls = 1                   (resolves only after getConnection)
gatewayState = "open"                 (ready is published while adoption is still pending)

With this PR the atom carries atlas before getConnection() runs, and the open transition still publishes.

[teknium1]

Thanks for carrying the saved-primary-profile boot ordering fix forward from #50529. The premise remains valid on current main: cold boot calls desktop.getConnection() before profile adoption (apps/desktop/src/app/gateway/hooks/use-gateway-boot.ts:470,499), while the profile atom controls REST routing and sidebar scope (apps/desktop/src/store/profile.ts:174-186,329-331).

The proposed pre-connect applyPrimaryProfile() is consistent with the registry contract: primary state only publishes when its profile matches activeKey, and the primary fast path in ensureGatewayForProfile() synchronously calls setActive (apps/desktop/src/store/gateway.ts:139-160,271-278). The ordering test also directly addresses the gap identified in #50529's review.

Automated hermes-sweeper review.

[GottZ]

This was generated by AI during triage.

Graph note (no action implied — a maintainer has already reviewed this thread).

Our triage graph places this PR in a complex with 3 related pull requests (#44443, #50529, #62624). They were checked against each other at the diff level and no consolidation is indicated — they address distinct causes.

Full neighbourhood: https://hermes-triage.gottz.de/?node=75112

This note exists so the relationship stays discoverable from the thread itself.