Bug: Verify model download integrity before promoting an artifact #113

Summary

A fixture declared a 100-byte model and an explicit SHA-256; a 13-byte corrupt response was still marked completed. model_downloader.py:171 promotes the partial file without validating the catalog checksum or expected size. Replacing a previous destination first unlinks it.

Environment and evidence

• Review finding: F13 (2026-10-05 product/technical review).
• Baseline: Windows, dev at c1c5dbe. The remote dev matched this commit when filing.
• Evidence: Reproduced.
• Priority recommendation: P1 - proposed first-release blocker. This is review triage, not a production-incident severity declaration.
• No real credentials, paid inference, engine installation, or unrelated process termination were used for review probes. Mocked observations establish the stated code behavior, not live-provider/GPU acceptance.

Reproduction or validation

Construct a HubModelRecord declaring size_bytes=100 and an explicit SHA-256. Feed DownloadWorker a mocked 13-byte corrupt HTTP response. Observed: status=completed and a promoted 13-byte destination. No model was downloaded from the network. Also inspect partial-file resume/source switching and replacement of an existing destination.

User impact

Truncated or incorrect models can be offered as usable; replacement can discard a working file before promotion succeeds. Resume/fallback also needs Content-Range and source-identity validation.

Proposed approach

Verify length and checksum where available, reject invalid resumptions, and atomically replace only validated artifacts while preserving the previous version on failure.

Acceptance criteria

• Validate expected length and checksum where supplied before promotion.
• Reject incompatible Content-Range, ETag/source identity, or resume responses.
• Promotion is atomic and preserves a previous valid model on failure.
• Invalid downloads remain failed/incomplete with actionable diagnostics.

Verification scope

Real GPU inference, paid-provider compatibility, and a clean-machine packaged desktop journey remain unverified. Any follow-up implementation should target dev under the repository's contribution/branching rules.