feat(circuits): add variable-length BLAKE3 gadget and wire it into the example

[gopikannappan]

What. Adds binius_circuits::blake3::blake3_variable, a BLAKE3 hash gadget whose message length is a runtime witness bounded by a compile-time capacity — the BLAKE3 analog of Sha256::new. Wires it into the blake3 example so --max-message-len is accepted (previously rejected), and removes the example's single-chunk restriction.

Note one thing I found while scoping this: the blake3_fixed TODO about multi-chunk support is stale — blake3_fixed/blake3_tree_root already handle multi-chunk messages. The genuine remaining gap is a runtime-variable-length gadget (the Sha256::new analog), which is what this adds.

Why. BLAKE3 only had blake3_fixed (compile-time length). Applications that verify variable-length inputs bounded by a max had no BLAKE3 option, unlike SHA-256/SHA-512/Keccak.

How. For a length-len message the digest is fixed by the final-block index bd, its byte length fbl, and the content; all blocks before bd are full, so the chunk/tree shape follows from bd. Following the SHA-256 variable circuit's approach: mask the message tail to zero against len_bytes; build one candidate digest per possible final-block index (reusing the exact blake3_fixed chunk/tree machinery, sharing full interior chunks, with only the final block's block_len as a runtime wire); then multi_wire_multiplex the candidate at bd. len_bytes <= max_len_bytes is enforced so the multiplex selector stays in range.

Testing. New unit tests compare the circuit digest against the blake3 crate across empty, single-block, single-chunk, multi-chunk, and non-aligned capacities, plus an overlong-length rejection test. cargo test -p binius-circuits -p binius-examples green; fmt/clippy clean; example proves+verifies end-to-end for variable messages.

Known limitation (flagging honestly). This builds max_blocks candidate digests, each rebuilding its chunk + parent tree, so circuit size is roughly quadratic in max_blocks. I chose the clearly-correct construction over the optimal one for a first pass; a production version likely wants an incremental CV-stack (à la BLAKE3 streaming) or shared sub-tree nodes across candidates to reach ~O(max_blocks). Happy to follow up with that if you'd prefer it before merge.

Also flagging unrelated pre-existing drift I noticed: blake3 check-snapshot fails on the default fixed circuit on pristine HEAD too (verified via git stash) — the committed snapshot looks stale relative to current main. This PR leaves the default fixed-length circuit shape untouched, so I did not re-bless it.

Authored with Claude Code.

[jimpo]

Awesome, thanks! Will review soon