76a95d0

[macOS release] imported/w3c/web-platform-tests/event-timing/keydown is a flaky text failure.
rdar://174354241
https://bugs.webkit.org/show_bug.cgi?id=311759

Reviewed by NOBODY (OOPS!).

The test uses event-timing-test-utils.js to create intentionally "slow" events and verify they are reported.
A PerformanceObserver is set up with durationThreshold: 16 — meaning events with duration ≥ 16ms should be reported.
The test then blocks the main thread for durationThreshold + 4 = 20ms to create a slow event.

The problem is that 20ms sits exactly on an 8ms rounding boundary. The Event Timing spec requires
durations to be rounded to the nearest 8ms for security ("The duration has an 8 millisecond granularity"). The
boundary between rounding to 16ms vs 24ms is at exactly 20.0ms. Additionally, WebKit spec states performance.now()
precision is 1ms. Since mainThreadBusy(20) uses performance.now() in its busy-wait loop, the 1ms floor quantization
means it can block for as little as ~19ms depending on where the initial timestamp falls relative to a 1ms tick. A
raw duration of 19ms rounds to 16ms instead of 24ms.

When the duration rounds to 16ms, the entry is still delivered to the observer (16 ≥ 16 satisfies the threshold),
but the verification assertion entry.duration + 4 >= entry.processingEnd - entry.startTime fails — because 16 + 4 = 20
is not greater than or equal to the actual processing time of ~20+ms (processingEnd - startTime includes more than just
the busy-wait — it also includes the dispatch delay (time from event creation to handler invocation))

The fix is to change the blocking duration from durationThreshold + 4 (20ms) to durationThreshold + 5 (21ms), which
provides enough margin that even with worst-case clock quantization, the raw duration stays above the 20ms rounding
boundary and always rounds to 24ms.

* LayoutTests/imported/w3c/web-platform-tests/event-timing/resources/event-timing-test-utils.js:
* LayoutTests/platform/mac-wk2/TestExpectations:

76a95d0