[feat] Improve macOS VirGL frame pacing by reducing GPU fence polling delay

[Fail-Safe]

Problem and change

On the macOS ANGLE/VirGL path, QEMU waits 10 ms before polling pending GPU fences again. That exceeds the 8.33 ms frame period of a 120 Hz display and can delay guest progress into a later frame.

Add a checksum-pinned QEMU source patch that uses a 1 ms interval under CONFIG_DARWIN. Other platforms retain 10 ms, and the existing pending command/fence queue check still controls timer rearming. No guest protocol or package changes are required.

This overlaps with the GPU fence polling portion of #168 and follows its Darwin-scoped implementation. It intentionally leaves the display refresh timestamp change, HDR, video decoding, and audio timer changes to that PR.

Existing experimental evidence

A controlled 10 ms → 1 ms → 10 ms comparison on an M3 Max, using a native Wayland/EGL client with presentation feedback, produced:

Interval	Presentations/s at 120 Hz	Median submit-to-presentation time
Original 10 ms	~60	~32.4 ms
1 ms	~120	~15.8 ms
Restored 10 ms	~60	~32.4 ms

At 60 Hz, both intervals sustained approximately 60 presentations/s. Simple clears and a workload with 200 scissored rectangle clears showed the same pattern. Runs lasted 12 seconds and excluded the first two seconds from steady-state summaries.

These measure guest virtual-display presentation, not physical panel scanout or end-to-end input latency. The isolated A/B/A experiment used a diagnostic binary modification; it is supporting evidence, not validation of the final source-built package. A later source-built integration of #168 also reached approximately 120 presentations/s, but included other display changes.

Validation and draft status

• Source patch applies in a dry run against the retained pinned QEMU source fixture.
• Build script shell syntax and whitespace checks pass.
• Full make test passed using the installed Xcode toolchain, including 242 Swift tests in 54 suites and the guest, build/cache, shell, and storage checks. The initial Command Line Tools run failed to load Swift Testing macros; the Xcode rerun resolved that toolchain issue.

Before marking ready:

• Build and test the standalone source-built packaged runtime.
• Repeat controlled 60/120 Hz comparisons on that package.
• Measure host CPU usage and wakeups at idle and under sustained load.
• Check resizing, refresh-rate transitions, background/foreground, and suspend/resume.

More frequent polling can increase CPU usage and wakeups while GPU work remains pending. This PR remains a draft until the standalone runtime and that tradeoff are validated.