perf: wait for NV12 export surfaces without millisecond sleeps

[AatmanAJ]

#2450 stopped the NV12 readback wait from sleeping in tokio's 1 ms ticks. The surface waits that exports actually use were left alone:

• PendingNv12Surface::wait: the default macOS export path.
• PendingNv12External::wait: the Linux external-memory path.

Both still yield ten times, then sleep 100 µs at a time. tokio rounds that up to a full millisecond, longer than a frame's GPU work, so whenever the previous frame's GPU work takes longer than about ten polls, the render loop wakes up late.

This PR uses the same pattern as the readback wait: spin on yield_now for NV12_READBACK_SPIN, then sleep only once a frame is slow. Only export (and the render farm and examples) use these NV12 waits. The editor's BGRA PendingSurface wait is untouched, so playback doesn't start spinning.

Results

Measured with the cap CLI on an M5 Max, macOS 27. The source is a real 61 s, 3006×1480, 60 fps Studio recording. The command was cap export … --fps 60 --quality social, with 5 interleaved runs per case; medians are shown.

Export	Before	After
1280×720	6.27 s, 536 fps encode, 4.0 s CPU	5.58 s, 606 fps encode, 3.2 s CPU (−11% wall time)
1920×1080	9.99 s	9.93 s (encoder-bound, so no change expected)

The gain shows up whenever export is render-bound, as at 720p here. 1080p and 4K on this machine are limited by the VideoToolbox encoder instead. Total CPU time went down at 720p, because less time is spent waiting.

A useful cross-check: before this change, CAP_EXPORT_DISABLE_ZERO_COPY=1 (the readback path, which already had the fix) was faster than the default zero-copy path, at 5.56 s vs 5.95 s, despite its extra copies.

Correctness

• The before and after outputs decode to identical frames: PSNR is inf, both have 3210 frames, and the decoded YUV md5 matches.
• cargo test -p cap-rendering --lib: 296 passed.
• cargo clippy -p cap-rendering -- -D warnings is clean.