Potential inconsistency when partial object writes occur during fetch: missing blobs may not be recovered

Bug Description

In the current fetch implementation (e.g., in remote.go), the logic for determining which objects to request (wants) relies primarily on whether the commit object referenced by a remote ref exists locally: https://github.com/go-git/go-git/blob/16e6d0af8b41d2a9920ddb0363cf9917ef6ed028/remote.go#L988

However, this approach assumes that if the commit object exists, then its entire object graph (tree, blobs, etc.) is also complete and valid.

This assumption can break in rare but possible scenarios — for example:

• During a previous fetch, the commit object was successfully written to .git/objects/, but a subsequent blob or tree object failed to write (e.g., due to disk full, I/O error, or process crash).
• The local repository now contains a dangling or incomplete object graph: the commit exists, but one or more of its referenced objects (tree/blob) are missing or corrupted.
• On the next fetch, since objectExists returns true for the commit, it is not added to the wants list, and the missing dependent objects are never re-fetched.
• As a result, the repository remains in an inconsistent state, and operations like checkout or status may fail with "missing blob" or "corrupt tree" errors.

Question: Should go-git enhance its objectExists-based logic to also validate the integrity of the commit’s object graph before deciding to skip it in wants? For example:

• Attempt to parse the commit and its root tree (without loading all blobs).
• If any referenced object is missing, treat the commit as incomplete and include it in wants.

Thanks for considering this edge case!

go-git Version

v5.11.0

Steps to Reproduce

No response

Additional Information

No response