Fix Menu keyboard navigation inside nested submenus (#42804)

* Fix Menu keyboard navigation inside nested submenus

Arrow keys collected only the direct `.menu-item` children of `.menu`, so
they skipped every submenu trigger, which sits at `.menu > .submenu >
.menu-item`. A menu built entirely from submenus had no reachable items.

Keys pressed inside an open submenu panel did nothing at all. The keydown
handler is delegated on both the toggle and `.menu`, and delegation stops
at the innermost match, so the handler ran on the nested `.menu`. From
there the toggle is not a sibling, and the last-resort lookup only
searched the `.submenu` wrapper. The handler bailed out before any branch,
which killed the arrows, Home, End and Escape. Escape left the user unable
to dismiss the menu by keyboard. The same lookup also picked the first
toggle in the document when a menu used `container`, so an arrow key could
open an unrelated menu.

Resolve the owning menu from the open instances first, and treat submenu
triggers as items of their parent level. Moving focus along a level now
closes the submenus focus left behind, which matches hover and click.

Two specs claimed to cover the submenu ArrowLeft and Escape paths but
called the methods directly instead of dispatching keys, and a third
asserted nothing. That is why the regression stayed hidden. All three now
dispatch real events, and new specs cover the arrows, Home, End, ArrowLeft
and Escape inside open submenus, a third level, and the `container` case.

Co-authored-by: Aljo Joby <141745680+aljojoby9@users.noreply.github.com>

* Merge the duplicate submenu open branches in Menu

Enter, Space and the RTL-aware enter arrow each opened a submenu through
their own copy of the same sixteen lines. Only the key test differed, so
one guard covers all three.

* Mark Menu submenu triggers as popups on init

A submenu trigger only got `aria-haspopup` when its submenu first opened,
and it never got a starting `aria-expanded`. Assistive technology
therefore gave no hint that a submenu existed until the user had already
opened it.

Set both attributes on every `.submenu > .menu-item` that wraps a nested
`.menu`, at any depth, when the instance is created. A closed menu is
`display: none`, so the triggers enter the accessibility tree only after
the toggle builds the instance, which keeps the lazy data API correct. An
author supplied `aria-expanded` is left alone, for a submenu that must
start open.

* Raise the minified JS budgets by a quarter kilobyte

The keyboard and aria work adds about 190 bytes to each minified bundle,
which left both budgets with roughly a hundred bytes of room. The next
small addition to any component would have failed CI for no reason of its
own. Raise both by one step so the ceiling moves on purpose rather than
during an unrelated review.

---------

Co-authored-by: Aljo Joby <141745680+aljojoby9@users.noreply.github.com>