fix(upgrade): stream prebuilt-download with progress so it can't silent-hang (#284.3)

[laulpogan]

Part 3 of #284 (Willard's Windows report).

Summary

With no `cargo` on PATH, `wire upgrade` correctly falls through to its prebuilt-release download path. But the download itself called `resp.bytes()`, which blocks until the entire body lands — silently. On Willard's Windows host that looked like a hard hang: zero stderr, no progress, the binary's mtime unchanged, and yet `crates.io` + `github.com` were both reachable. The operator had no way to tell whether the request was making forward progress, blocked on TLS, or wedged on something else, and bypassed the upgrade entirely with a manual `curl` + SHA verify (which is exactly what this code path was supposed to remove the need for).

Fix

Stream the download in 64 KiB chunks and emit progress to stderr at most every 500ms:

```
wire upgrade: downloaded 6291456 / 12308480 bytes (51%)
…
wire upgrade: downloaded 12308480 / 12308480 bytes (100%) in 4.218s
```

Edge cases covered:

Server response	Rendered
Has `Content-Length`	percent vs total
No `Content-Length`	`downloaded N bytes (unknown size)`
`Content-Length: 0` (degenerate)	same as missing — avoids divide-by-zero
Overshoot (server sent more bytes than `Content-Length` promised)	percent clamps at 100%

The existing 120s wall-clock timeout on the blocking reqwest client stays as the hard backstop. No new dep.

Pure-logic

`format_download_progress(got: u64, expected: Option) -> String` is split out so the format is unit-testable without touching reqwest.

Tests

4 new in `upgrade::tests`, all green on `x86_64-pc-windows-msvc` (rustc 1.96.0):

• `format_download_progress_includes_percent_when_total_known`
• `format_download_progress_clamps_percent_at_100_when_overshoot`
• `format_download_progress_falls_back_to_unknown_size_when_total_missing`
• `format_download_progress_falls_back_to_unknown_size_when_total_zero`

Full lib suite: 490 passed; 0 failed; 7 ignored.

Out of scope

Switching to a hard total-wall-clock timeout enforced by a watchdog thread (so a wedged TLS read can't ride past the reqwest timeout in pathological cases) is a follow-up if Windows reqwest 120s turns out to leak in practice. Today's 120s reqwest timeout + visible progress is the smallest fix that turns "silent hang" into "observable progress or loud failure"; that's enough to close the operator-experience hole.

Stack

Stacks on top of #294 (Windows test/clippy hygiene). Sibling Windows-cluster PRs already open: #296 (#284.5), #297 (#247.4), #298 (#284.1), #300 (#284.2).

Test plan

• `cargo fmt --check` clean on Windows.
• `cargo clippy --all-targets -- -D warnings` clean on Windows.
• `cargo test --lib` 490/0/7 on Windows.
• CI green.
• Manual: `wire upgrade` on a host with no cargo + a newer release published, confirm the progress line redraws and the final `in ` line lands. (Hard to reproduce the original silent-hang outside Willard's box, but verifying the progress UX works on a healthy host is the right smoke check.)

🤖 Generated with Claude Code

[cloudflare-workers-and-pages]

Deploying wireup-landing with    Cloudflare Pages

Latest commit:	250beb0
Status:	✅  Deploy successful!
Preview URL:	https://5923e661.wireup-landing.pages.dev
Branch Preview URL:	https://fix-284-3-wire-upgrade-prebu.wireup-landing.pages.dev

View logs