fix: guard inert feature detection against undefined HTMLElement.prototype

[mvanhorn]

Closes #10219

✅ Pull Request Checklist:

• Included link to corresponding React Spectrum GitHub Issue.
• Added/updated unit tests and storybook for this change (for new code or code which already has tests).
• Filled out test instructions.
• Updated documentation (if it already exists for this component). No user-facing docs exist for this internal feature-detection guard.
• Looked at the Accessibility Practices for this feature - Aria Practices

📝 Test Instructions:

The module-level supportsInert detection in packages/react-aria/src/overlays/ariaHideOutside.ts evaluated 'inert' in HTMLElement.prototype after only checking that HTMLElement was defined. In some bundler/SSR setups (reported with Next.js/Turbopack reloads) HTMLElement exists but HTMLElement.prototype is undefined, so the in operator threw TypeError: Cannot use 'in' operator to search for 'inert' in undefined at import time.

This adds a HTMLElement.prototype != null guard before the in check. When the prototype is missing, supportsInert now resolves to false, the same path used in environments without inert support, and the code falls back to aria-hidden. Behavior in a normal DOM is unchanged.

To verify:

• yarn jest packages/react-aria/test/overlays/ariaHideOutside.test.js passes, including two new cases under ariaHideOutside inert feature detection that import the module with HTMLElement.prototype undefined and with HTMLElement undefined and assert no throw.
• In a normal DOM the existing tests still confirm elements are hidden via the inert path.

🧢 Your Project:

Personal open source contribution.

[snowystinger]

In general looks good, verified that the test broke before the fix and passes with it

[snowystinger]

when does this one happen?