[Bug]: Composer command menu stays behind when the right panel or terminal drawer opens

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/web

Steps to reproduce

1. vp run dev on main at 2a04db134, in a wide window (measured at a 2200px viewport, where the composer is centred well inside max-w-3xl).
2. Open a thread or the new-thread draft and type / in the composer so the command menu opens. It is correctly anchored at this point.
3. Click Toggle right panel.

Expected behavior

The menu tracks the composer as the panel slides it, which is what #5336 set out to fix.

Actual behavior

The menu stays where the composer used to be. Left edges of the menu portal and of the composer anchor (the relative px-3 pb-2 sm:px-4 div that setComposerMenuAnchor is attached to):

	composer anchor	menu	drift
panel closed	845	845	0
panel opened	575	845	270

It does not recover on its own — still 845 after 3s. Dispatching window.resize snaps it to 575, so the anchoring maths is fine; the update just never happens. Toggling again leaves it one state behind in the same way.

The terminal drawer reproduces the vertical case, which is the overlap #5336 also aimed at. Composer anchor top vs menu bottom:

	menu bottom	anchor top	gap
drawer closed	371	379	+8
drawer open	371	239	-132 (overlapping)

Reproduces in both the draft view and a real thread.

Impact

Minor bug or occasional failure

(Minor in consequence, but it reproduces every time, not occasionally.)

Version or commit

main @ 2a04db134

Environment

macOS 15 (Darwin 25.5.0), Chromium, 2200x900 viewport, vp run dev.

Logs or stack traces

(no console errors; this is a layout/position issue)

Workaround

Any window resize re-anchors the menu.

---

Measurements that may help

ComposerCommandMenuLayer positions the portal from the anchor's rect and refreshes on window resize, window scroll, and a ResizeObserver on the anchor plus every ancestor. Walking the anchor's 20-element ancestor chain across a panel toggle:

• indices 7-13 do change width (1904 -> 1364 and 1944 -> 1404), so there is something for a ResizeObserver to see;
• indices 0-6 only move (845 -> 575) and never change size — that includes the anchor itself, mx-auto w-full min-w-0 max-w-3xl, and the glass host/shell;
• the only non-zero transition durations in the chain are background-color and color at 0.2s, so the inline comment's "they resize on every frame of the panel animation" does not appear to describe what happens — the widths change in one step.

One observation I could not explain: attaching my own ResizeObserver to the same 20 elements and toggling the panel recorded zero notifications, while the widths above demonstrably changed. That may well be my instrumentation rather than the browser, so please treat it as a hint to check whether the observer's callbacks are actually being delivered here, not as a diagnosis.

What worked downstream was to stop relying on a single notification and instead re-measure on animation frames until the position stops changing, then stop. That fixes both the horizontal and vertical cases and costs 2 animation frames per idle second with the menu open, but it treats the symptom — I never established why the existing update is lost.

No PR, since CONTRIBUTING asks for issues first. Happy to send a small patch if it would be useful.

Start in apps/web by locating ComposerCommandMenuLayer and reproduce the issue with vp run dev on the referenced main commit, in both a draft and a real thread. Inspect how anchor updates respond to the right panel and terminal drawer, then verify the menu follows the composer without a window resize in both horizontal and vertical cases.