`make_program_cache_key`: blake2b is not a FIPS-compliant hash

[leofang]

make_program_cache_key (added in #1912) uses hashlib.blake2b for cache key derivation. blake2b is not FIPS-approved, so hashlib.blake2b() raises ValueError on FIPS-compliant Linux systems:

ValueError: [digital envelope routines: EVP_DigestInit_ex] disabled for FIPS

This is common in government/DOE supercomputer environments — exactly where CUDA workloads run. CuPy hit the same issue with hashlib.md5 (cupy/cupy#5959, fixed in cupy/cupy#5988 by switching to SHA-1).

Note: FileStreamProgramCache._path_for_key also uses hashlib.blake2b to hash keys into filesystem paths — this needs the same fix.

Proposed fix

1. Switch from blake2b to a FIPS-approved hash. Two options:
   • SHA-1 (20-byte digest, FIPS-approved) — matches CuPy's choice. Faster than SHA-256. 160-bit collision resistance is more than sufficient for cache keys.
   • SHA-256 (32-byte digest, FIPS-approved) — drop-in replacement for the current blake2b(digest_size=32). Slightly slower but stronger.
2. Remove both the hash algorithm name AND the digest size from the public make_program_cache_key docstring — the Returns section currently says "A 32-byte blake2b digest." Both the algorithm and the size are implementation details that may change (e.g., switching to SHA-1 changes the size from 32 to 20 bytes). The return type should just be documented as bytes.
3. Bump _KEY_SCHEMA_VERSION to invalidate old caches (old blake2b entries become orphans, reaped by eviction).

[leofang]

• Remove both the hash algorithm name AND the digest size from the public make_program_cache_key docstring

I will address this in #2032. The rest can wait post-1.0.

[cpcloud]

This should really be added to the agents file to prevent most problems like this going forward.