Notebook Webview scroll distance is improperly reduced

Does this issue occur when all extensions are disabled?: **Yes**

- VS Code Version: `1.129.1`
- Commit: `8a7abeba6e03ea3af87bfbce9a1b7e48fed567b8`
- Electron: `42.6.0`
- Chrome: `148.0.7778.280`
- OS Version: Ubuntu `24.04.4 LTS` (X11), Linux `7.0.0-28-generic`, x64
- Display configuration: GNOME display scale factor `2`; VS Code window zoom level `1`
- Installed notebook-related extensions:
- `ms-toolsai.jupyter 2025.9.1`
- `ms-toolsai.jupyter-renderers 1.3.0`

## Summary

In a native Jupyter Notebook, physical mouse-wheel scrolling has a different distance depending on the pointer target:

- Over a code cell, the outer Notebook scroll distance is normal.
- Over a rendered Markdown cell or a regular inline output, the outer Notebook scroll distance is much shorter for the same wheel input.

This is a stable distance/multiplier problem, not a performance problem: there is no visible jank, blocking, or delayed rendering.

## Steps to Reproduce

1. On a display with a device scale factor greater than 1, open the attached minimal `.ipynb` in VS Code.
2. Ensure the notebook contains a code cell, a rendered Markdown cell, and a code cell with an existing ordinary text output. No kernel execution is required.
3. Place the pointer over the code cell and scroll the physical mouse wheel by one comparable notch. Observe the change in the outer Notebook scroll position.
4. Return to the same starting position. Place the pointer over the rendered Markdown cell and repeat the same wheel input.
5. Repeat step 4 with the pointer over the regular cell output.

## Expected Behaviour

The outer Notebook scroll distance should be consistent for the same physical wheel input, regardless of whether the pointer is over a code cell, rendered Markdown, or a non-scrollable inline output.

## Actual Behaviour

The rendered Markdown and inline output paths scroll a much shorter distance than the code-cell path. The reduction is consistent with an extra division by `window.devicePixelRatio`.

## Investigation / Suspected Root Cause

The Notebook Webview forwards wheel events using `wheelDelta*` values. In the current source, it divides these values by `window.devicePixelRatio` for every Chrome-based runtime:

https://github.com/microsoft/vscode/blob/main/src/vs/workbench/contrib/notebook/browser/view/renderers/webviewPreloads.ts#L676-L694

However, the host-side `StandardWheelEvent` only applies that DPR workaround for Chrome `<= 122`, because Chrome `>= 123` has the upstream fix:

https://github.com/microsoft/vscode/blob/main/src/vs/base/browser/mouseEvent.ts#L138-L162

On Chrome 148, the two paths therefore differ:

```text
Code cell:
native wheelDeltaY -> StandardWheelEvent -> wheelDeltaY / 120

Markdown/output Webview:
native wheelDeltaY -> wheelDeltaY / devicePixelRatio
-> did-scroll-wheel -> StandardWheelEvent -> wheelDeltaY / devicePixelRatio / 120
```

The code-cell path does not use the Webview forwarding path. Notebook cell editors configure `handleMouseWheel: false`, allowing the native wheel event to reach the Notebook list directly.

The code comments in both places refer to the historical DPR workaround discussed in https://github.com/microsoft/vscode/issues/146403#issuecomment-1854538928. The host path has since added a Chrome-version gate, while the Notebook Webview path appears not to have added the same gate.

## Possible Fix Direction

Please make the Notebook Webview use the same Chrome-version condition as `StandardWheelEvent`, so DPR normalization is applied only for Chrome `<= 122`, or centralize this normalization to avoid divergent compatibility logic.

## Additional Information

- I found no `editor.mouseWheelScrollSensitivity`, `workbench.list.mouseWheelScrollSensitivity`, or smooth-scrolling override in user or workspace settings.
- Recording: https://github.com/user-attachments/assets/f5da1aa2-9187-4bb4-906d-b5a75f893ab5
- Minimal reproduction notebook: [notebook-scroll-distance-repro.ipynb](https://github.com/user-attachments/files/31206697/notebook-scroll-distance-repro.ipynb)
- Developer Tools Console after reproduction: No Notebook/Webview-related errors or warnings were observed in the latest renderer and notebook-rendering logs. The renderer log contains unrelated extension-marketplace network failures, Agent/Chat extension messages, and Node deprecation warnings; those are omitted because they are not triggered by or relevant to this reproduction.
- Latest Insiders result: Not tested. However, the suspected code path has not yet changed upstream.

## Why This Is a New Issue

The following currently open issues were reviewed and are not duplicates:

- `#251347`: large Notebook outputs flicker and later scroll slowly;
- `#203547`: slow scrolling can become stuck at a particular title;
- `#117644`: historical general Notebook scroll performance and jitter;
- `#112134`: a general request to respect the system mouse-scroll-speed setting.

This report is specifically about a deterministic, pointer-target-dependent
wheel-distance mismatch caused by the Webview message path on high-DPI Chrome
runtimes.