fix(core): parse a hex id without chunks_exact, which clippy now rejects

[youhide]

CI on main is red on all three platforms and this unblocks it. Not a plan item — a prerequisite for the one in #77.

What happened

Nothing about the code changed its mind; the lint did. A newer clippy on the CI runners raises clippy::chunks_exact_to_as_chunks for chunks_exact(2) over a constant. Clippy warnings are errors in this workspace, so hidegit-core stopped compiling under cargo clippy everywhere.

It is invisible locally: this machine has clippy 0.1.97, the runners have newer.

Why not the lint's own suggestion

as_chunks stabilised in exactly the version this workspace declares as its floor — 1.88, which rust-toolchain.toml and the MSRV job both pin. Putting a parser of untrusted repository input on the precise edge of the declared minimum is closer than it needs to be, and the MSRV job runs cargo check, not clippy, so it would not have been the thing to catch a mistake there.

Indexing is simpler and older than both spellings:

for i in 0..hex.len() / 2 {
    let pair = hex.get(i * 2..i * 2 + 2)?;
    buf[i] = u8::from_str_radix(pair, 16).ok()?;
}

str::get on a byte range yields None for anything that is not a character boundary, so a multi-byte character is rejected before it reaches the radix parser rather than after — which is exactly what the std::str::from_utf8 call it replaces was there to do. One fewer step, same refusals.

Behaviour

Unchanged. The three existing ObjectId tests cover the round trip, the SHA-256 length, and the malformed input that must be refused — all still pass, and no test needed touching, which is the point.

Gate

cargo fmt --all -- --check and cargo test -p hidegit-core green locally. The clippy half can only be verified by CI, since the lint does not exist in this machine's toolchain — that is the whole reason this PR exists.