fix(visaged): unbreak CI — clippy 1.98 lint, without raising MSRV

[ccross2]

main is red, and no commit caused it

Run history for the identical SHA 63c9fbc:

when	result
2026-08-18 17:12	success
2026-08-24 06:51	failure

The code did not change; the toolchain did. CI resolves dtolnay/rust-toolchain@stable, which floated onto a Rust whose clippy adds chunks_exact_to_as_chunks. With -D warnings, a new lint is an immediate failure on untouched code — and it blocks every merge in the repo, not just this one.

error: using `chunks_exact` with a constant chunk size
   --> crates/visaged/src/store.rs:336:24

Why neither obvious fix works

• clippy's own suggestion, as_chunks::<4>() — stabilized in Rust 1.88.0 (rust-lang/rust#139656), against this crate's declared rust-version = "1.75". Taking the suggestion would raise MSRV by thirteen minor versions, which versioning-discipline classes as a breaking change for consumers.
• #[allow(clippy::chunks_exact_to_as_chunks)] — names a lint that does not exist before clippy 1.98, so it trips unknown_lints on any older toolchain. That trades one failure for another.

So the loop indexes explicitly. It is correct on every toolchain from 1.75 upward and couples to no lint name. The slice bounds cannot panic: bytes.len() == EMBEDDING_BYTE_LEN is checked immediately above, and EMBEDDING_BYTE_LEN == EMBEDDING_DIM * 4.

Verification

• fmt clean, clippy clean, 81 tests pass across 9 suites.
• Coverage of the rewritten line proven by injecting a one-character defect (let start = i * 4 + 1), which fails 5 tests — test_embedding_byte_fidelity, test_strict_rejects_nan, test_strict_rejects_infinity, test_roundtrip, test_encryption_roundtrip — then restoring from a snapshot and re-confirming green.

Stated limitation: the local toolchain is 1.95 and does not carry this lint, so I could not reproduce-then-confirm against the real lint locally. CI on this PR is the check that matters.

Not addressed here

CI is nondeterministic by construction: a floating stable toolchain plus -D warnings means the build can go red with no commit, which is exactly what happened. Pinning the toolchain is a maintainer policy call and deserves its own decision rather than riding along in a fix.

🤖 Generated with Claude Code