phc: add_b64_bytes keeps the ParamsString invariants - #2462

ParamsString is meant to always hold a valid parameter string: iter() expects it with INVARIANT_VIOLATED_MSG, and FromStr validates every name and value. add_decimal and add_str go through add(), which rejects duplicates and leaves the buffer unchanged on overflow. add_b64_bytes writes straight into the buffer instead, and that breaks the invariant three ways:

let mut p = ParamsString::new();
p.add_decimal("m", 1).unwrap();
p.add_b64_bytes("m", b"x").unwrap();        // Ok: "m=1,m=eA" (add_decimal/add_str reject this)

let mut p = ParamsString::new();
p.add_b64_bytes("data", &[0xAB; 60]).unwrap(); // Ok: 80-char value, > Value::MAX_LENGTH (64)
ParamsString::from_str(p.as_str());         // Err(ParamValueTooLong)

let mut p = ParamsString::new();
p.add_decimal("a", 1).unwrap();
p.add_b64_bytes("data", &[0xAB; 90]);       // Err(Base64(InvalidLength)), but p is now "a=1,data="

End to end, a PasswordHash whose params were built with add_b64_bytes and 49–88 bytes of data (Argon2's data/keyid params are B64) serializes to a PHC string that PasswordHash::new rejects with "parameter value too long".

The fix encodes into a Value::MAX_LENGTH scratch buffer, validates the result as a Value, and adds it through add(), like the other add_* methods. Existing output is unchanged (a=AQ,b=AgM,c=BAUG).

Test: add_b64_bytes_invariants in params.rs covers the duplicate name, the 64-char boundary (48 bytes ok, 49 bytes ParamValueTooLong with nothing written), and an overflow of the total length that leaves the params unchanged. It fails on master. The phc.yml matrix passed locally: powerset tests on stable and 1.85, thumbv7em/wasm32 powerset build, fmt, clippy.

This PR was produced by AI agents (Claude) and reviewed by me before submission.