fix(setup): drain child pipes while the child runs, not after it exits

[thcp]

Fixes #516. Targets fix/510-updater-url-allowlist -- both touch main.rs and the plan sequences the Rust changes. Merge #528 first.

The problem

child_output_with_timeout read the pipes only after try_wait() reported an exit:

loop {
    if let Some(status) = child.try_wait()? {
        // read_to_end on stdout/stderr -- only reachable once the child is gone
    }
    thread::sleep(Duration::from_millis(100));
}

A child that outruns the OS pipe buffer blocks in write() with nobody reading, so it never exits, so try_wait() never reports an exit. The call ends at the timeout with no output.

warmup_models pipes both streams (main.rs:1414-1415) and its model downloads emit tqdm progress to stderr in proportion to how long they take, not how large they are. The failure therefore lands on slow connections -- exactly the users warmup exists to spare a mid-pipeline download.

Change

Each stream drains on its own thread. Both are required: draining one then the other reintroduces the deadlock on whichever is second. Readers are joined rather than detached on the timeout path, since killing the child closes its ends and dropping the handles would leak two threads per timeout.

command_output_with_timeout had the identical shape and now delegates, so the two cannot drift apart again.

Verification -- the deadlock is reproduced, not assumed

New test a_chatty_child_is_drained_rather_than_deadlocked writes 512 KiB to each stream.

implementation	result
read-after-exit (old)	FAILED -- "chatty child timed out after 20 seconds", took 20.09s
concurrent draining (this PR)	passed in 0.11s

Worth recording: when I filed #516 I measured a real cold-cache warmup on a fast connection and found only 8,360 bytes of stderr -- under the buffer. That is why this had not been hit in practice, not why it could not happen. The test settles it.

cargo fmt --check   OK
cargo clippy        0 errors
cargo test          59 passed, 1 failed

The 1 failure is tests::a_free_port_is_granted_as_asked, the known parallel-execution flake, failing 3/3 on the base branch without this change.

One thing to check in review

While rewriting command_output_with_timeout I initially sliced out the #[cfg(windows)] attribute above hide_console_window, which cargo check caught immediately. Restored, and both hide_console_window definitions keep their cfg guards -- worth a glance since a Linux/macOS-only compile would not exercise the Windows one.