#2902 setup: SHA-256 check is wrong for large shards and deletes correct files

本文

## Summary

The SHA-256 check in `setup.py` is wrong for large files (the failures we see are 43–50 GB shards): it rejects a correct file, deletes it, downloads it again, and the next attempt fails the same way. Small files hash fine, so the bug only shows on the big model shards.

## What happens

```
checking Qwen3.8-Flash-Next-UD-IQ4_XS-00002-of-00003.gguf (SHA-256, 49.8 GB) ...
[X] ... has the wrong SHA-256 (cd6e40937ddf0f39d68748f1f086b423565fcb8a6d0a32f4ac52a5be35d8f744,
    expected 577a38a2392b40ca2193cea502e1d92f60b8cd370675d308e0ec21885d9daaa7): deleted
```

After a fresh 49.8 GB download the check reports another value (`ec899c68…`); shard 3 (43.8 GB) fails the same way (`e2f8d605…` vs expected `d4634e6d…`).

## Proof that the bytes are fine and the check is not

* Same file, external hasher (`certutil -hashfile <file> SHA256`): **`577a38a2…`** — exactly the `lfs.oid` the Hub publishes for `unsloth/Qwen3.8-Flash-Next-GGUF`, both on `main` and on the commit pinned in `setup.py` (`38bb39ee…`).
* Shard 3, same external hasher: **`d4634e6d…`** — its Hub oid. Setup's own check on those same bytes said `e2f8d605…` and deleted the file.

Environment: Windows 10 19045, Python 3.13.13, Strata 0.1.45.

## Correct way to verify these files

Use an external hasher instead of `hashlib`:

* Windows: `certutil -hashfile "<file>" SHA256`
* macOS / Linux: `shasum -a 256 "<file>"`

and compare the result with the file's `lfs.oid` from the Hub API
(`https://huggingface.co/api/models/<repo>/tree/<ref>/<dir>?expand=true`).

## Also: do not delete on a mismatch

Rename the file to `<name>.bad` and keep it. Then a mismatch costs a re-check, not another 50 GB download, and the user still has the bytes for a manual verification.

## Workaround for users today

Put `<file>.done` next to the file containing `sha256 <expected>` — `verify_sha256` then skips the check. The `whole (checked against its own tensor directory)` form written by `whole_shard` is not enough for a pinned hash: it still re-hashes.