[ZEPPELIN-6559] Drop the faked Windows user agent so Monaco keybindings match the host platform

[voidmatcha]

What is this PR for?

playwright.config.js builds the chromium project from devices['Desktop Chrome'], whose userAgent is a hardcoded Windows NT 10.0 string regardless of the host. Monaco picks its keybinding platform by sniffing that user agent, while Playwright's key resolution (ControlOrMeta) and the browser's native text editing follow the real OS. On a macOS host those disagree, and two things break.

1. Ctrl+P and Ctrl+N are never claimed by Monaco. The keydown reaches the document with defaultPrevented === false, so macOS Chromium runs its native Emacs-style caret binding inside Monaco's hidden textarea. The next typed character then lands in the wrong place: pressing Control+P and typing MARKER yields M on its own line and line2ARKER below it.
2. Meta+A select-all is a silent no-op. pressSelectAll resolves ControlOrMeta+A to Meta+A on macOS, but Windows-mode Monaco only binds Ctrl+A. No model event fires, so every select-all in the suite quietly did nothing locally.

Linux CI is unaffected because its Chromium build has no native caret bindings, which is why this only ever showed up locally. Real users are not affected either: with a genuine macOS user agent Monaco runs in mac mode and calls preventDefault. This is a test-harness defect only.

Unsetting the override is what Playwright recommends for this case (https://playwright.dev/docs/emulation#devices):

Pre-configured devices assume a specific platform. For example, "Desktop Chrome" will provide a Windows-specific user agent string. If you would like to use the user agent specific to the platform that is running the tests, we recommend unsetting the user agent property.

webkit deliberately keeps its Desktop Safari mac user agent, because the page objects' Meta+A branch depends on it.

Local (macOS) and CI (Linux) no longer share one keybinding platform as a result. That uniformity was not worth keeping: under it, select-all on macOS produced no model event at all, so the suite ran locally without exercising what it claimed to.

What type of PR is it?

Bug Fix

Todos

• Verify navigator.userAgent reports the host platform after the change
• Run the keyboard spec on macOS
• Run the full chromium suite on CI

What is the Jira issue?

ZEPPELIN-6559

How should this be tested?

CI covers the regression side: the full chromium suite reports 546 passed with no failure attributable to this change.

The fix itself is only observable on a macOS host:

cd zeppelin-web-angular
npm run start
npx playwright test e2e/tests/notebook/keyboard/ --project=chromium

Before: 3 passed, 1 failed (ParagraphActions.MoveCursorUp: Control+P). Because the suite is describe.serial, that first failure blocks every later test in the file.
After: 31 passed, 0 failed.

To confirm the user agent directly, read navigator.userAgent in any spec. It changes from the Windows NT 10.0 string to Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) ....

Screenshots (if appropriate)

N/A

Questions:

• Does the license files need to update? No
• Is there breaking changes for older versions? No
• Does this needs documentation? No

[tbonelee]

Merged into master