Verify CrispEmbed runtime downloads before install

[Blackspirits]

Summary

CrispEmbed runtime archives are downloaded by CrispEmbedDownloadService and unpacked immediately by the OCR installer. The matching SHA-256 values already exist in DownloadHashManager, but the downloaded archive bytes were not authenticated before extraction.

This change:

• pairs each CrispEmbed runtime URL with its exact existing archive hash key
• verifies the downloaded stream before the installer can write the install sidecar or unpack it
• covers Windows CUDA/Vulkan/CPU, Linux CUDA/default x64/ARM64, and macOS ARM64
• fails closed when a hash key or digest is missing
• rewinds the verified stream for the existing sidecar/unpack flow
• leaves GGUF model downloads unchanged because the current model metadata exposes size floors but no pinned SHA-256
• adds regression coverage for all 7 current archive digests, the real HTTP download path, unknown-key fail-closed behavior, and stream rewind after rejection

Validation

• no digest values were added or changed
• all seven current registry hashes were independently compared with the sha256: digests published by the official CrispStrobe/CrispEmbed v0.17.9 release; all seven match
• full solution restore passed
• full solution build passed
• full solution test suite passed on the first run
• retry step was not used
• validation run: #34628063509

Base is upstream 10b4b012fdb1e31edbff09ab69370c1c50ed9374. Upstream has since advanced, but the intervening commits do not touch the CrispEmbed runtime download/hash/install path.

AI assistance: ChatGPT was used to audit the CrispEmbed runtime download/install paths, compare the pinned hashes with official GitHub release asset digests, prepare the minimal integrity fix, and add regression coverage.