0.2.5

fix(bootstrap): detect truncated browser downloads, clean retry

A Windows user hit "tar ZIP bad CRC" on every file when extracting the
CloakBrowser archive — the signature of a truncated/corrupt download of
the ~280MB binary. Two gaps let it through:

1. download() never checked received bytes against the content-length
   header. fetch + pipeline resolve "successfully" even when the socket
   drops mid-transfer (network blip, antivirus/proxy closing the
   connection), leaving a partial file that fails extraction.
2. SHA-256 verification only runs when the release ships a SHA256SUMS
   asset. When it's absent, the check is skipped entirely and corrupt
   bytes flow straight to extraction.

Fixes:
- Truncation guard in download(): if content-length is known and the
  received byte count doesn't match, delete the partial and throw an
  actionable error (retry / antivirus exclusion).
- Wrap extractArchive in try/catch that scrubs both the .zip.partial
  and the .partial extract dir on failure, so the next launch
  re-downloads from scratch instead of choking on the same bad file,
  and surfaces a clear retry message.

Both guards work independently of whether the release publishes a hash.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>