Customizable <select>'s button and selectedcontent are not treated as inert, causing false button-name violations

### Product

axe-core

### Product Version

4.13.0

### Latest Version

- [x] I have tested the issue with the latest version of the product

### Issue Description

#### Expectation

`axe.run()` should not report a `button-name` violation for the internal `` used by a customizable `` (`……`). Per the HTML spec, that `` and its `` child are inert — excluded from the accessibility tree and not focusable — so `button-name` (and any other rule relying on accessibility-tree visibility or focusability) should treat them as inapplicable, not as a naming violation.

#### Actual

axe-core has no awareness of this select-specific inert rule. `lib/commons/dom/is-inert.js` only accounts for the `inert` attribute and elements outside an open modal ``. As a result, the scan sees a `` with no text, no `aria-label`, and no wrapping ``, and reports a `critical` `button-name` violation on it. The same gap can also affect any other rule that depends on `isVisibleToScreenReaders`, `isFocusable`, or `isInert` for this subtree (e.g. `nested-interactive`, `color-contrast`).

#### How to Reproduce

```js
axe.run(document.body).then(results => {
console.log(results.violations);
});
```

against this fixture:

```html

Apple
Banana

```

`results.violations` includes a `button-name` violation for the ``, even though it is spec-inert and never exposed to assistive technology.

#### Additional context

Suggested fix: teach `isInert` (`lib/commons/dom/is-inert.js`) that any `` that is a direct child of a ``, and any `` element, are inert per [the HTML spec's `select` element definition](https://html.spec.whatwg.org/multipage/form-elements.html#the-select-element). This should apply regardless of the select's rendered `appearance` (`base-select` vs. the default UA widget) — inertness comes from being a `select`'s button/selectedcontent, not from how it's styled. This propagates automatically to `isVisibleToScreenReaders` and `focusDisabled`/`isFocusable`, which already delegate to `isInert`. `axe.runVirtualRule('button-name', …)` bypasses the gather-time visibility filter, so `button-name`'s `matches` function should also be updated to skip inert nodes directly.

Related: #4836 tracks a separate, complementary ARIA-in-HTML standards update (disallowing ARIA roles/attributes on `selectedcontent`/the select button, plus a `role=generic` fallback for a misused `selectedcontent`) — that issue is about `standards/` data and does not cover this inert/focusability gap.

Start with lib/commons/dom/is-inert.js and trace how isInert feeds isVisibleToScreenReaders and isFocusable. Then inspect button-name's matches function for the axe.runVirtualRule path. Done means the customizable select button and selectedcontent are treated as inert, with no false button-name violation in either scan path, regardless of rendered appearance.

Written by the indexing model from the issue text.