fix: stream model downloads with incremental progress bar

[tyvsmith]

Summary

• The download_model function previously buffered the entire HTTP response into memory with response.bytes() before writing to disk or updating the progress bar
• For the 166MB arcface_r50 model, this made the download appear frozen with no progress indication
• Replaced bulk buffering with an 8KB chunked streaming loop using std::io::Read on the blocking reqwest::Response, writing each chunk to the temp file and updating the progress bar incrementally
• Preserved the atomic write pattern (write to .tmp, then rename), the 600s timeout, the SHA256 verification, and the progress bar style unchanged

Test plan

• cargo build --workspace passes
• cargo clippy --workspace -- -D warnings passes with zero warnings
• cargo test --workspace passes
• Manually verify: running facelock setup shows live progress during large model downloads instead of appearing frozen

🤖 Generated with Claude Code

[Copilot]

Pull request overview

This PR improves the UX of facelock setup model downloads by switching download_model from buffering the full HTTP response in memory to streaming the response to disk while updating the progress bar incrementally.

Changes:

• Stream the blocking reqwest::Response body in ~8KB chunks and write incrementally to the temporary file.
• Update the progress bar position during streaming to avoid “frozen” appearance on large downloads.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The use std::io::Read as _; inside the loop is easy to miss and suggests per-iteration work even though it’s only needed to bring the trait into scope. Consider moving the use to just before the loop. Also, since this is purely progress accounting, using pb.inc(n as u64) would let you drop the separate downloaded counter and set_position bookkeeping.