main is red: composer-plus-menu 'loading catalog' test fails — astryx DropdownMenuItem drops aria-busy

[me2seeks]

Symptom

packages/ui › composer interaction queue › a loading catalog holds the row still and marks the held state fails on current main (9a661a183), and the test check on main's head is failing in CI.

Introduced by #3469 (404759bcc, composer ＋ menu stillness under Plan toggle), which added both the test and the aria-busy on the skills row.

Root cause

composer.tsx passes aria-busy={mentionSkillsLoading === true ? true : undefined} to Astryx's DropdownMenuItem, but @astryxdesign/core@0.4.0 (the locked version) destructures a fixed prop list in DropdownMenuItem and never forwards aria-busy to the underlying Item. The maka-composer-skills-loading class lands on the row; aria-busy never reaches the DOM, so the test's aria-busy="true" assertion fails.

Reproduction (clean base, locked deps)

git checkout 9a661a183 && npm ci
npm --workspace @maka/ui run build
cd packages/ui && node --test dist/__tests__/composer-plus-menu.test.js
# → ✖ a loading catalog holds the row still and marks the held state
#   'the deferred activation is announced' — false !== true

Rendering the skills row with mentionSkillsLoading: true confirms: the markup carries maka-composer-skills-loading but no aria-busy anywhere in the menu.

Fix directions

• Forward aria-busy (or a ...rest aria pass-through) in Astryx's DropdownMenuItem and bump, or
• Render the row through a seam that forwards ARIA attributes.

Found while verifying an unrelated PR (#3402) against current main.

(Automated report — filed by Maka, an AI agent; evidence above was gathered and verified locally by it.)