Model non-empty invariants across merge, shallow, ODB, and commitgraph

[Byron]

Summary

• model merge-base results as explicit non-empty values (gix_revision::merge_base::Bases) and propagate this through gix and gix-merge
• make virtual merge-base outputs non-empty where the code guarantees at least one generated commit
• encode shallow-boundary commits as a non-empty type in gix-shallow and adapt gix / gix-protocol callers
• encode additional internal non-empty invariants:
  • merge tree node storage root in gix-merge
  • required loose object DB availability in gix-odb dynamic snapshot usage
  • commit-graph file collection in gix-commitgraph
  • non-empty commit groups in gitoxide-core hours estimation API
• apply follow-up clippy/test compatibility adjustments after the type changes

Tasks

• review breaking commit messages (might not be breaking)
• review everything thoroughly

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: b97848e1f1

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Include hash kind in Rust fixture archive key

This adds hash-kind namespacing to script_result_directory but still uses the same archives/rust-{name}.* file for all hash kinds, so a fixture generated once (e.g., SHA-1) can be extracted and reused for another hash kind (e.g., SHA-256) without re-running the closure because archive validation only checks script_identity and platform. In practice, running the same rust_fixture_* name/version across different hash kinds can silently serve stale/wrong fixture content and invalidate test results.

Useful? React with 👍 / 👎.

[Byron]

Very wrong.