[High] Patch rust for CVE-2026-82254

[BinduSri-6522866]

Summary:
Patch rust for CVE-2026-82254
Commits 1–5: zero deviations — same as upstream. But 6 deviations are in commit 6.
GitoxideLabs/gitoxide@b32a847 - Prerequisite — don't panic on unknown entry types (from_bytes/File::entry → Result)
GitoxideLabs/gitoxide@bad5b48e4f0d - Prerequisite — adapt gix-odb to commit-1
GitoxideLabs/gitoxide@0be338f - Prerequisite -Handle OOM when copying to buffers — adds Error::OutOfMemory + From
GitoxideLabs/gitoxide@fce7095 - Prerequisite - gix-pack: delta application is a fallible operation (PR #2059)
GitoxideLabs/gitoxide@56ca4bf - Prerequisite - refactor: put error into more specific spot and export it → pub mod apply
GitoxideLabs/gitoxide@1dc8ede - the CVE-2026-82254 fix

Deviation 1 — data/delta.rs (1 line)
Upstream: size |= (u64::from(*cmd) & 0x7f) << shift;
Ours: size |= (*cmd as u64 & 0x7f) << shift;
Why: The commit only renamed the variable i → shift on this line. The u64::from vs as u64 style came from an unrelated clippy cleanup that isn't in our 0.44.0 baseline.
Impact: None — identical machine code. Keeping as u64 matches the surrounding file.

Deviation 2 — data/entry/decode.rs (5 lines, one change)
Upstream: gix_hash::ObjectId::from_bytes_or_panic(...)
Ours: gix_hash::ObjectId::from(...)
Why: from_bytes_or_panic is a rename that landed in gix-hash after 0.44.0. Our vendored gix-hash only exposes from — the same function under the old name.
Impact: None. It spans 5 lines because the shorter name made rustfmt rewrap the block; I applied rustfmt's canonical form, so the file is format-clean.

Deviation 3 — data/file/decode/header.rs (1 line)
Upstream: )?)?;
Ours: )?)?
Why: Trailing semicolon only. Our pristine baseline had no semicolon here either.
Impact: None — it's the final expression of a match-arm block, where the semicolon is optional.

Deviation 4 — data/file/init.rs (2 doc lines)
Upstream:
/// Use [Self::from_data()] together with [File::with_alloc_limit_bytes()][...]
/// when working with untrusted input.
Why: References from_data(), which doesn't exist in 0.44.0 — keeping it would be a broken intra-doc link.
Impact: None. Replaced with upstream's own alternative wording from the same commit, which describes our at() accurately.

Deviation 5 — multi_index/init.rs (6 lines)
Upstream: impl TryFrom<&Path> for Filecrate::MMap, pub fn from_data_with_alloc_limit_bytes, data: T, and two doc links to from_data().
Why: Our File isn't generic and there's no public from_data() in 0.44.0.
Impact: None. Ours uses impl File, data: Mmap, a private helper of the same name, and doc links retargeted to File::at(). Same structure and ordering as upstream.

Deviation 6 — multi_index/write.rs (2 doc lines) — hunk not applied
Upstream:
/// The error returned by [crate::multi_index::write_from_index_paths()].
/// The progress ids used in [crate::multi_index::write_from_index_paths()].
Why: Two reasons. The pre-image text doesn't exist in our file (ours already uses a different doc-link form), so the hunk can't match. And the replacement points at a free function, while in our tree it's a method on File.
Impact: None — pure doc comments. Applying it would replace working links with broken ones.

Additinally test/ folder is not present, so test changes are not applied.

[azure-pipelines]

Azure Pipelines:
There may be pipelines that require an authorized user to comment /azp run to run.