window.menuStyle default differs between stable and insiders on macOS

`window.menuStyle` currently resolves to a different default depending on build quality, in [`desktop.contribution.ts`](https://github.com/microsoft/vscode/blob/main/src/vs/workbench/electron-browser/desktop.contribution.ts#L284):

```ts
'default': product.quality !== 'stable' ? 'inherit' : (isMacintosh ? 'native' : 'inherit'), // TODO@bpasero figure out the default
```

So on macOS:

| Quality | Effective default | Context menus |
| --- | --- | --- |
| Stable | `native` | Native OS menus |
| Insiders / Exploration | `inherit` | Custom HTML menus (with the default custom title bar) |

Linux/Windows resolve to `inherit` for every quality, so the divergence is macOS only. The existing `TODO@bpasero figure out the default` suggests this was always meant to be revisited, and it is still present on `main` and `release/1.132`.

### Why this matters

Insiders is supposed to be the preview of what ships to stable, but for this setting the two qualities exercise entirely different code paths on macOS: `NativeContextMenuService` vs. `HTMLContextMenuService` (see `hasNativeContextMenu` in `src/vs/platform/window/common/window.ts`). Any regression in the custom menu path on macOS is invisible to stable users, and any regression in the native menu path is invisible to insiders users. That is exactly the kind of difference that escapes our validation until release.

### How this surfaced

The `Integrated Browser` smoke suite drives the browser toolbar overflow menu and the `Add to Chat` menu through DOM locators:

```
.monaco-menu-container:visible .action-menu-item
```

Native menus never create a `.monaco-menu-container` element, so the suite passed on insiders and failed on stable — even when both builds were produced from the **same** `release/1.132` commit:

```
locator.waitFor: Timeout 30000ms exceeded.
- waiting for locator('.monaco-menu-container:visible .action-menu-item').filter({ hasText: 'Site Permissions' }).last()
```

The follow-on `"after each" hook` timeout was a cascade: the native menu stayed open, so closing the browser page never completed. Retries did not help, since the mismatch is deterministic per quality.

That failure was unblocked by pinning the setting for the suite in #328969, but that only makes the test deterministic — it does not resolve the underlying question of what the default should be.

### Proposal

Decide on a single intended default for `window.menuStyle` on macOS and align the qualities:

- If `native` is the intended macOS experience, insiders should default to it too, so insiders users actually preview what stable ships.
- If `inherit`/custom is the direction, stable should move to it, and the quality check can be dropped entirely.