Windows: pet_watch output_failures_do_not_stop_the_world asserts sink.failed() before the audio path records it

`Test (windows-latest)` fails on `v0914-chunk2` (PR #6175), one test out of 15271:

```
FAIL [0.849s] (12432/15271) codewhale-tui tui::pet_watch::worker::tests::output_failures_do_not_stop_the_world
panicked at crates\tui\src\tui\pet_watch\worker.rs:412:9:
assertion failed: sink.failed()
Summary [624.861s] 15271 tests run: 15270 passed (1 leaky), 1 failed, 20 skipped
```

Passes on ubuntu and macOS. Windows only.

## What the test does

```rust
let worker = Worker::start(None).unwrap();
let (sink, packets) = audio::Output::capture();
drop(packets); // no receiver left
frame_with_audio(&worker, 0.0, Some(sink.target()));
let before = frame_with_audio(&worker, 400.0, Some(sink.target()));
assert!(sink.failed()); // <-- fails here on Windows
```

## Why it is probably ordering, not correctness

`frame_with_audio` sends `Command::Advance` and then polls `worker.latest` until a raster appears, with a 10-second bound. So it synchronises on the **raster** being published — but `sink.failed()` is a flag on the **audio** path. A published raster does not, on the face of it, guarantee that the audio send has been attempted and its failure recorded.

If that is right, the test assumes an ordering that holds incidentally on unix thread scheduling and not on Windows, and the fix is to poll `sink.failed()` with a bounded wait — the same idiom this file already uses for the raster — which would not weaken the assertion.

**But that is exactly the assumption someone who owns this code should check rather than me.** If the audio failure is *supposed* to be recorded by the time the raster is published, then Windows is exposing a real defect in the audio path and adding a wait would mask it. I do not know the delivery semantics well enough to tell those apart, so I have not touched it.

## Context

This is the second Windows/platform issue in the pet slice tonight; `portable` (Pet conformance) is also red on the same branch, on a TypeScript↔Rust frame-hash parity mismatch, and has been since `a06d2296`. There is also uncommitted pet work (`pet_sim.rs`, `pet_widget.rs`, `pet_cameo.rs`) sitting in the `codewhale` checkout that may already change this code, which is a further reason not to patch it from outside.

Not a blocker for #6175 per the founder's call on the pet slice, but `main`'s Windows CI will be red until this is resolved.

Last touched by `c5ea6992cf` and `5c70db41f0`.

Start in crates/tui/src/tui/pet_watch/worker.rs at the output_failures_do_not_stop_the_world test, then inspect Worker::start, frame_with_audio, and audio::Output::capture to verify whether raster publication orders audio failure recording. Reproduce the test on Windows. Done means the ordering is validated and the test reliably distinguishes a scheduling race from an audio-path defect without weakening its assertion.

Written by the indexing model from the issue text.