Preserve ancestor scroll positions when focusing the native edit context

[nstrayer]

Fixes #324758

If you try and embed monaco editors in scrollable documents things can get a bit funky. We noticed this in Positron and fixed it there but if other VSCode forks or new vscode editors also end up embedding editors in native scrollable documents in the future the issues will show up so I figured an upstream PR was worth it to get ahead of those issues and save headaches for future people who get super confused about this scrolling behavior like I did!

Agent generated notes 👇

When the native EditContext input path focuses the hidden edit context node, the browser scrolls every scrollable ancestor to reveal it. The node is parked at the editor's last cursor position, so in hosts where Monaco's ancestors scroll natively (overflow: auto), focusing the editor yanks the container's scroll position and can shift layout between the mouse-down hit test and click resolution, placing the cursor on the wrong line.

The textarea input path has guarded against exactly this for years in writeNativeTextAreaContent ("browsers will try really hard to reveal the textarea... we try to undo the browser's desperate reveal"). This PR mirrors that guard in FocusTracker.focus() using the existing saveParentsScrollTop / restoreParentsScrollTop helpers from base/browser/dom.ts.

VS Code's own surfaces don't show the bug because workbench scrolling is synthetic and ListView neutralizes browser-initiated scrolls; it only manifests for embedders. Repro harness, before/after measurements, and verification against a monaco-editor-core build from this branch are in #324758. Downstream, Positron carries this fix with a Playwright regression test (posit-dev/positron#14696).

Note: the IME-toggle handler in nativeEditContext.ts calls this.domNode.focus() directly, bypassing FocusTracker.focus(). It is not in the click path and is left untouched here.