fix(desktop): keep the composer ＋ menu still when toggling Plan

[MatrixA]

Summary

Clicking Plan in the composer's ＋ menu made the open menu visibly blink: the toggle re-fetches the invocable-Skill projection, the fail-closed clear leaves mentionSkills empty for the length of the IPC round trip, and the Skills row read that transient [] as "no skills available" — graying out and growing a description line, then snapping back. useComposerMentions now also returns a settled mentionSkillsUnavailable verdict that only moves when a request resolves; the Skills row renders from it, while the / popup keeps reading the fail-closed list. A second commit removes the pending-keyed disable that dimmed the Plan/Swarm/Graph rows and the footer mode marks to half opacity during a toggle's commit round trip — the pending registries already swallow re-entrant toggles, so the disable protected nothing and only blinked.

Root cause

use-composer-mentions.ts clears the list while re-fetching on purpose (a visible / popup must never advertise a stale Skill), and newSessionCollaborationMode is a dependency of that effect, so length === 0 could not tell "re-fetching" from "nothing to offer". The same blip fired in sessions via the mode-change event, and on model or turn changes.

Verification

Before — the menu jumps on the Plan click	After — the menu holds still

• packages/ui: 192/192 unit tests pass, including three new tests pinning the Skills row's presentation (refreshing ≠ empty; settled-empty keeps its caveat; populated stays quiet).
• apps/desktop: 1060/1060 main-process tests pass; typecheck and biome lint clean on every touched file.
• e2e: composer-plus-menu-stability.spec.ts now carries three specs. The stability spec arms an in-page MutationObserver before the click and asserts the menu stays open, keeps one height, and never shows the transient "no skills" line or a grayed row. Two review-round specs hold IPC in-flight windows open via a preload latch (isolated-E2E gate only): a Skills click mid-refresh does nothing and works once settled, and two rapid Plan toggles land on the last requested state. All three fail without their fix; adjacent composer specs (skill invocation, slash-command menu, send-message) still pass, 9/9 total.

AI use

Select exactly one:

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

Tool(s) and scope: Claude Code (Claude Fable 5) diagnosed the flicker and authored the fix, unit tests and e2e spec; both commits carry Generated-by: Claude Code trailers.

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

🤖 Generated with Claude Code

[Astro-Han]

Thanks for addressing the visible menu jump and removing the unnecessary pending repaint. The direction is good, and both findings below are non-blocking P2s. They cover two short in-flight windows where the controls now look actionable but the underlying authority cannot honor the click.

A clean final state would give the Skill catalog one explicit loading/empty/populated representation, and either expose a real pending mode state without changing menu geometry or preserve the user’s latest toggle intent.

AI-assisted review disclosure: Codex coordinated independent state-authority and UI/test review passes against exact head 1beb6d2b399856bc39ac73e60efafc1d32dee2e1; I reviewed the consolidated evidence for this comment.

[Astro-Han]

Thanks for fixing the two earlier behavior regressions — the menu now keeps its geometry and the latest toggle intent wins on the main interaction path. Two independent passes rechecked this exact head. I kept one accessibility P2 and a few small lifecycle/simplification edges inline; the clean final state is one keyed lifecycle representation for both the catalog and queued mode intent, with loading exposed semantically rather than only visually.

AI-assisted review disclosure: OpenAI Codex coordinated two independent review passes. I verified the retained findings against this exact head and the current live PR state, and I made the final review decision.

[Astro-Han]

Thanks — the approach here is the part worth calling out: this fixes the jitter by removing state rather than adding a correction for it.

What this solves / how: toggling Plan made the composer's ＋ menu shift, and the Skills row could briefly show the previous context's skills or swallow the loading state entirely. Rather than compensating for the movement, this removes what caused the re-render — the write-only pending mode state — and makes the skill catalog fail closed on a context-key mismatch so a stale list can't paint for a frame.

Review notes:

• Keying the skill catalog on contextKey (session/project/model/mode/target) and returning an empty list on mismatch is the right default: showing nothing briefly is honest, showing another context's skills is not.
• Dropping setPendingCollaborationModeBySession and friends is the substantive change. Pending state that only ever gets written and never read still costs a render, and that render was the blink. Holding it in the registry ref instead means the value is still available where it's needed without driving the view.
• aria-busy with the gate inside the handler rather than a remount — keeps focus where the user left it.
• Net effect is two concepts gone (the write-only pending states) plus the write-implies-rerender coupling, with the responsibility moving to the registry ref. Nothing was added to compensate.

Worth noting for anyone reading this later: the tempting fix for "menu jumps" is a position offset, which would have left both the stale-render and the focus-loss problems in place while adding a third thing to maintain. This went after the cause instead.

LGTM.

---

AI-assisted review. Verified against this exact head with CI green.