Stop the proxy test hanging Windows CI for six hours

[mattpodwysocki]

Fixes the build (windows-2022) failure on #12 — which isn't #12's fault. That PR is a one-line CODEOWNERS file from a bot; it's just the first run left undisturbed long enough to hit the six-hour job timeout.

What's happening

The last thing the Windows log says before the gap is my test, from #5:

test an_https_proxy_in_the_environment_is_used has been running for over 60 seconds
   … 5.95 hours …
##[error]The operation was canceled.

It's been broken on main since #5 merged. Nobody saw it because every main run during the 0.2.0 merges was cancelled by the next push well inside six hours.

Two faults; the second is what turned a failure into a wedge

The environment. The test used env_clear() and put PATH back. On Windows that takes SystemRoot with it, and without SystemRoot the socket and TLS stacks can't initialise — so the CLI failed before it could reach any proxy. tests/update_check.rs spawns the binary too and uses targeted env_remove; this now matches it, and additionally clears the proxy variables so a developer's own HTTPS_PROXY can't change the result.

The unbounded wait. It blocked on accept() with no deadline, on a thread it then joined. So "the CLI never connected" was indistinguishable from "the CLI hasn't connected yet", and the job sat there until GitHub killed it.

accept_within now bounds it at 30 seconds. Nothing arriving is a result, reported as a failure that names the variable and quotes what the CLI said.

Verified, not assumed

With the CLI made to bypass the proxy so nothing connects:

test an_https_proxy_in_the_environment_is_used ... FAILED
panicked at tests/proxy.rs:79:9:
nothing reached the fake proxy within 3s, so HTTPS_PROXY was not used. The CLI said: …
test result: FAILED. … finished in 3.01s

3.01 seconds, with a diagnosable message, instead of six hours.

Being straight about the split: the environment change is the diagnosis and the deadline is the guarantee. I can't run Windows here, so if SystemRoot wasn't the whole story, the test will now say so in half a minute rather than burning a runner — and the message will carry the CLI's own stderr to say why.

Also spawns the child instead of running it to completion, since the connection only arrives while it's running. That removes the thread entirely.

588 tests, fmt and clippy clean.

Worth a follow-up, separately

build (windows-2022) evidently isn't a required check — #5 merged with it unfinished, and so did several others during the 0.2.0 run. A six-hour timeout also means a genuine Windows break costs a runner for six hours before anyone hears about it. Both are worth revisiting: a timeout-minutes on that job would turn the next one into a fast, loud failure.