Fix the flaky capture-loop test at its cause, not its timeout

[Purple10101]

Why

test_refresh_failure_does_not_kill_capture_loop fails roughly 1 run in 20, on any machine. It took main red after an unrelated merge, and cost a re-run on #75 before that.

It is not a slow runner, and raising the timeout would not have helped.

Cause

_run() only re-renders when new_frames_since_render > 0, and the first render resets that counter:

do_render = has_viewers and (
    self._refresh_requested
    or (new_frames_since_render > 0 and now - last_render >= RENDER_INTERVAL_S)
)

The capture thread starts on service.start() and consumes frames every POLL_INTERVAL_S while the main thread is still on its way to attach(). With a fixed two-frame list there is a race: if both frames are gone before a viewer is registered, the first render fires on _refresh_requested, the counter resets, no frame ever arrives again, and the second render can never happen. calls["n"] sticks at 1 and the wait expires however long it is.

Fix

The test now takes frames from a source that never runs out, so a second render is reachable whatever order the threads happen to run in. The assertion then tests what it means to test, that the loop survives an exception, rather than incidentally testing thread scheduling.

FakeBlah2Client is deliberately left alone: other tests assert on a fixed frame count and rely on it draining.

Measured

	failures
Before, on this branch's base	2 / 25
Before, on origin/main	2 / 50
After	0 / 150

Full suite: 802 passing.