Pre-seed Integrated Browser smoke settings to avoid the relaunch prompt - #328972

Follow-up to #328969, which is already merged.

That PR pinned window.menuStyle to custom for the Integrated Browser suite by writing it through the settings editor. That fixed the macOS stable/insiders divergence, but it introduced a new failure on Linux CI in the very first test:

locator.fill: Timeout 30000ms exceeded.
  - waiting for locator('.quick-input-widget:visible input[placeholder*="enter URL"]')
    - locator resolved to <input ... aria-label="Search or enter URL" .../>
    - element is not visible

Cause

window.menuStyle is watched by SettingsChangeRelauncher, which on Windows/Linux treats a change to it as requiring a restart:

// Windows/Linux: Menu style
processChanged(!isMacintosh && this.menuStyle.handleChange(config.window?.menuStyle));

Writing the setting at runtime therefore popped a modal dialog ("A setting has changed that requires a restart to take effect.") over the workbench. The quick input was still in the DOM, but obscured by the modal, so fill never became possible. This was a real regression, not flakiness — it is deterministic on Windows/Linux, and it does not reproduce on macOS because the relauncher deliberately skips menuStyle there.

Fix

Seed both settings into settings.json before the application starts, in the existing beforeStart hook, instead of writing them once the window is up:

• The values are already in effect when the window opens, so nothing "changes" and no relaunch prompt appears.
• workbench.browser.experimentalUserTools.enabled moves with it — it is declared experiment: { mode: 'startup' }, so it is better applied at startup anyway.
• The suite no longer touches the settings editor at all, matching the pattern already used by the Chat Sessions and Agents Window suites.

The reason for pinning custom is unchanged and is now captured in a comment on the helper. The underlying question of what the default should be is tracked in #328970.