Upstream libgit2 builtin sha256 may have race condition

This was found in * https://github.com/rust-lang/git2-rs/actions/runs/25859716266/job/75986211798?pr=1206#step:6:237 * https://github.com/rust-lang/git2-rs/actions/runs/25944613082/job/76269915137?pr=1206#step:6:253 * https://github.com/rust-lang/git2-rs/actions/runs/25859252887/job/75984686679?pr=1206#step:6:237 during `cargo test` which the test harness libtest is multi-threaded. ``` thread 'indexer::tests::indexer_sha256' (11949) panicked at src/test.rs:36:14: called `Result::unwrap()` on an `Err` value: Error { code: -33, klass: 9, message: "object hash mismatch - expected 7991f5e7c0692696aec4fdf250571006878b2667a3123fbdb5329653591af542 but got 831eed201a25d1677172d9c5e6cc953308062f5e007f5e9a28c0e38250c17d8b" } ``` Observed them failed on different toolchains and platforms, and only when `unstable-sha256` is enabled with `http` feature deactivated. After some investigation, I found that in upstream libgit2. It use a static `addTemp` which doesn't have any thread-safe mechanism around it: https://github.com/libgit2/libgit2/blob/d23f18fd881b8c5bb5e7a7abfcbc71ddf0c9a5ea/src/util/hash/rfc6234/sha224-256.c#L86-L91 Combined with the "without `http` feature" finding, I think that means the `GIT_SHA256_BUILTIN` is not thread safe. This is not too hard to reproduce by adjust test running in a fairly amount of threads (i.e., 16 or 32) and rerunning the entire test suite a couple of times. cc https://github.com/rust-lang/git2-rs/pull/1206