RFC: replace `git2` with `gix` (`gitoxide`)

Nobody has claimed this yet.

The main limitation with using `libgit2` (via `git2`) is its dependency on OpenSSL for HTTPS transport. This introduces challenges for cross-compilation and increases the binary size due to the inclusion of an additional HTTP(S) stack.

An alternative is [`gix`](https://github.com/Byron/gitoxide), which supports pluggable HTTP clients such as reqwest—the same client we use elsewhere in our project. However, `gix` is currently not mature enough for our needs. It lacks support for critical operations such as `git reset --hard` or `git pull`, making it unsuitable for updating resources. Additionally, SSH transport is not built-in and relies on invoking the external `ssh` command.

Other Potential Solutions

- Replace git2’s HTTPS transport backend with an alternative client (e.g., git2-curl or git2-hyper). These crates are not widely adopted or actively maintained, creating long-term maintenance risk. Also, libssh2 (provide SSH transport) relies on OpenSSL for cryptographic primitives, so we cannot remove the OpenSSL dependency.
- Implement a custom update mechanism (maa-update-engine). This is currently only a proposal and would require substantial development effort and ongoing maintenance.

Start by auditing the current git2 usage and the resource update paths, then compare gix's supported operations and transport options with the requirements described here. Confirm whether reset, pull, HTTPS, and SSH can be supported without the current OpenSSL dependency. Done would require an agreed implementation path, since this RFC does not name files or tests.

Written by the indexing model from the issue text.