fix(desktop): honour the last profile pick during an in-flight switch

[ctaylor86]

What does this PR do?

If profile A is active, the user starts switching to B, then selects A again before B finishes connecting, Desktop can end on B despite the user's final selection being A. The “already active” fast path runs before the pending-switch mutex, so the final A request is discarded.

Delete that redundant pre-mutex check. The existing check after the mutex still avoids unnecessary work once earlier activation has settled. Production code changes by four deleted lines; no new state or coordinator is introduced.

Why it matters / suggested P2: this is a reproducible wrong-profile activation race, not cosmetic flicker. The workaround is to wait for B to finish and select A again. It affects the legacy profile activation path; this PR does not claim universal registry-switch ordering or failure-reporting coverage.

Related Issue

Related to #90149. The current patches for #105139 and #102673 do not change this pre-mutex early return. This is a separate, independently mergeable legacy activation-ordering fix.

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/store/profile.ts: remove the four-line early return before waiting for an in-flight switch.
• apps/desktop/src/store/profile-last-intent.test.ts: drive A → pending B → A through real profile/gateway/session stores; assert final profile, connection and socket identity, and the settled no-op behavior.

How to Test

1. Start with profile A connected; hold B's connection completion.
2. Request B, then request A before releasing B.
3. Release B. Before: the regression finishes on work (B), not default (A). After: the final A request waits and then wins; a subsequent settled A request remains a no-op.

Run against head 4ce4d4fa1769faa55eeecbe37929e584213a7a0e:

npm run test:ui -- src/store/profile-last-intent.test.ts src/store/profile.test.ts src/store/profile-switch-failure.test.ts src/store/profile-agent-activation.test.ts
npm run typecheck

Final-head verification: 35 tests / 4 files passed, plus all three Desktop TypeScript projects and git diff --check. The new behavioral regression was independently run against the unchanged base and failed with work instead of default.

Transport/UI effects are synthetic; profile, gateway and session stores are real. Production build was not rerun for this store-only patch. Failed legacy dials retain their existing rejection behavior; unrelated registry disposal/supersession behavior is unchanged.

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 26.3.1 (Apple Silicon); other operating systems not executed.

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.

[ctaylor86]

Priority clarification after updating the description: could this be considered P2 (reliability with a workaround) rather than the current P3?

The deferred real-store regression demonstrates A → pending B → A ending on B, contrary to the final explicit profile selection. Waiting for B and selecting A again is a workaround. Four deleted production lines move the existing no-op decision behind pending activation, preserving the settled no-op. This is limited to legacy profile activation ordering, not a universal switching claim.

The PR body now includes concise reproduction, the protected invariant, exact-head verification commands and explicit test limits. I am not requesting P1/P0; the severity decision remains with maintainers.