add blake2b and argon2id password hashing primitives to the runtime

[kacy]

summary

• hand-written blake2b (rfc 7693) in cranelift/runtime/src/blake2b.rs: keyed and unkeyed, digest lengths 1 to 64 bytes, incremental state plus a one-shot helper
• hand-written argon2id (rfc 9106) in cranelift/runtime/src/argon2.rs: the full memory-filling function with configurable time cost, memory cost, parallelism, salt, and output length. no new crate dependencies — ring offers neither primitive, and argon2id is defined in terms of blake2b
• the memory cost is an allocation request coming from whatever config supplied it, so the runtime caps it at 1 GiB and allocates with try_reserve_exact, returning an error instead of taking down the process on an oversized value
• exposed at the ffi boundary as crypto_blake2b and crypto_argon2id, following the existing crypto entries: bytes handles in, a bytes handle out, 0 on any invalid input

this is the primitive layer for a std.crypto.password module. making the two entries callable from pith needs builtin declarations in the self-hosted checker plus a bootstrap seed refresh, so that wiring is left for a follow-up rather than colliding with the seed change already in review.

what was tested

• blake2b: the rfc 7693 appendix vector ("abc"), official keyed kat values at 0, 1, 64, 128, 129, and 255 input bytes, truncated digests (20/32/48 bytes), keyed and truncated together, incremental-vs-one-shot equivalence, and rejection of out-of-range digest and key lengths
• argon2: all three rfc 9106 section 5 vectors — argon2d, argon2i, and argon2id. the d and i variants are test-only; they pin the reference-block indexing on both addressing paths, where a subtly wrong implementation still produces plausible output. plus determinism, salt and parameter sensitivity, long-tag h' chaining, and parameter-range rejections
• cargo test --release --workspace --locked: all suites green
• make test green (289/289 regressions), regression corpus also green under PITH_GREEN=0
• timing on this 2-core host (single-threaded fill): m=19 MiB t=2 p=1 about 45 ms, m=32 MiB t=3 p=1 about 100 ms, m=64 MiB t=3 p=4 about 700 ms

notes

the memory fill is single-threaded. lanes still changes the output exactly as the rfc requires; it just does not fan out across os threads. that keeps the code simple, and on this class of host the owasp-recommended parameters (19 MiB, t=2, p=1) land around 45 ms per hash, which is where the std module's defaults should sit.