MenuTrigger does not set isNonModal on PopoverContext, causing Popover to add role="dialog" around Menu

### Provide a general summary of the issue here

When using the `MenuTrigger` > `Popover` > `Menu` pattern, the `Popover` overlay element receives `role="dialog"`, which is incorrect for a menu popup. This happens because `MenuTrigger` does not pass `isNonModal: true` through `PopoverContext`, so `Popover` defaults to treating itself as a dialog.

This causes screen readers to announce "dialog" when opening a menu, which is confusing for users and does not match the expected semantics of the WAI-ARIA APG Menu Button pattern.

### 🤔 Expected Behavior?

When a `Popover` is used inside a `MenuTrigger`, the overlay element should **not** have `role="dialog"`. The popup should only contain `role="menu"` semantics, as specified by the [WAI-ARIA APG Menu and Menubar pattern](https://www.w3.org/WAI/ARIA/apg/patterns/menubar/).

A screen reader should announce something like:
> "Actions, menu button, collapsed" > (click) > "Open, 1 of 5"

No "dialog" should be announced.

### 😯 Current Behavior

The `Popover` overlay element gets `role="dialog"` ` even when used inside `MenuTrigger`.

A screen reader currently announces:
> "Actions, button" > (click) > "dialog, dialog, Open, 1 of 5"

### 💁 Possible Solution

Maybe add isNonModal: true to the PopoverContext value provided by MenuTrigger.

### 🔦 Context

We are building an accessible UI kit for that must comply with RGAA (the French transposition of WCAG). An our dropdown menus for announcing "dialog" via screen readers.

We use the recommended MenuTrigger > Popover > Menu pattern from react-aria-components. Since there is no clean way to prevent role="dialog" without using isNonModal (which has a warning discouraging its use), we aim to work around this with a MutationObserver that removes the attribute from the DOM as soon as Popover sets it.

### 🖥️ Steps to Reproduce

Open a menu with the screen reader enable and sees "dialog" displayling and check the popover in the DOM

### Version

1.16.0

### What browsers are you seeing the problem on?

Chrome

### If other, please specify.

_No response_

### What operating system are you using?

windows 11

### 🧢 Your Company/Team

_No response_

### 🕷 Tracking Issue

_No response_

Start by locating the MenuTrigger, PopoverContext, and Popover entry points described in the issue, then trace how the context controls the overlay role. Verify the existing menu-trigger pattern and add coverage for the reported behavior; done means the menu popup no longer receives role="dialog" while retaining role="menu" semantics.

Written by the indexing model from the issue text.