Add timeout to GitHub update-check HTTP client

[jrozner]

Summary

The ASHIRT API client already sets connect/request timeouts (src/ashirt/http.rs), but the GitHub release update check built a bare reqwest::blocking::Client::new() with no timeout, so an unresponsive api.github.com could hang the update check indefinitely.

This builds the update-check client with the same 10s connect / 30s request timeouts as the ASHIRT client.

Context

This addresses F-04 (CWE-400), originally raised against the pre-rewrite Go codebase in #142. That PR is stale (the Go code is gone after the Rust rewrite in #159); this reapplies the fix to the current Rust code.

While reviewing the other stale security PRs against the current codebase:

• F-07 (Restrict recording file and directory permissions #143, file permissions) and F-08 (Sanitize filename in rename to prevent path traversal #145, rename path traversal) are already handled in the Rust rewrite, with test coverage.
• F-06 (URL-encode operation slug in API path construction #146, URL-encode slug) is not a real issue under the actual threat model — the slug is server-provided in the normal flow and otherwise only sourced from the user's own config/CLI, so there's no trust boundary crossed.
• F-05 (Limit HTTP response body reads to 10MB #141, response body size cap) is intentionally out of scope here; it's low-value defense-in-depth since the client only talks to its own authenticated ASHIRT server and GitHub's metadata API.

Testing

cargo build clean; cargo test for the update module passes (21 tests).