Flaky macOS/WebKit test: virtual wall and monotonic clocks stay consistent

## Failing test

`virtualScheduling - createVirtualTimeApi without processor > virtual wall and monotonic clocks stay consistent`

The **macOS / Browser** job failed in WebKit on #336662:

- [Workflow run](https://github.com/microsoft/vscode/actions/runs/35290385962)
- [Failed job and logs](https://github.com/microsoft/vscode/actions/runs/35290385962/job/105431736782)
- [Test at the failing revision](https://github.com/microsoft/vscode/blob/636743ce28f0681c4318f358b96339da5722994a/src/vs/base/test/common/virtualScheduling/virtualScheduling.test.ts#L418-L451)

## Failure details

The final assertion compares the restored native `performance.timeOrigin` with its value before installing the virtual clock. They differed by **1 ms**:

```text
restoredPerformanceTimeOrigin
Expected: 1789690601071
Actual: 1789690601072
```

The fake-clock values and the restored `performance.now` function matched expectations. This was the only failure in that WebKit run: 28,887 passing, 137 pending, 1 failing.

## Local verification

A focused run on macOS/WebKit passed all 75 tests, including this test:

```sh
node test/unit/browser/index.js --browser webkit --runGlob '**/{fileActions,virtualScheduling}.test.js'
```

The triggering PR changes only Explorer paste error reporting and its regression test; it does not modify virtual scheduling. This appears to be an existing intermittent failure rather than an Explorer regression.

## Ownership

Assigned to @hediet based on git blame: the failing clock-origin assertion was introduced in #327980 ([commit](https://github.com/microsoft/vscode/commit/d790d7d957f685337ab8a7f15e6dbd74f4ffe139)).

No matching report was found by searching the exact test name, `virtualScheduling`, `restoredPerformanceTimeOrigin`, and existing clock-origin flakiness issues.