fix(fetch): enumerate commit parents without requiring them to be present

[sanity]

Closes #60.

Problem

Cloning could abort with:

error: git rev-list --parents <sha> failed: error: Could not read <parent>
fatal: Failed to traverse parents of commit <sha>

while every bundle was present and healthy on the network — freenet-git rescue against the same URL fetched all of them without error.

Cause

walk_unresolved_parents exists to answer "which of this commit's parents do I still need?", so the fetch loop knows which bundle to download next. It answered that with git rev-list --parents -n 1, which traverses, and therefore fails with Could not read <parent> exactly when a parent is absent.

So the walk returned Err precisely when it had something useful to report. The clone aborted instead of fetching the bundle carrying that parent.

Fix

Use git cat-file commit <sha> and parse the parent headers. That reads a single object, so it is answerable whether or not the parents are local.

Two details worth flagging for review:

• Header-only parsing. A commit object is headers, blank line, then free-form message. A message body can easily contain a line beginning with parent (a quoted log, a review note), so parsing past the blank line would invent parents out of prose. The parser stops at the blank line.
• Tag peeling preserved. cat-file commit peels an annotated tag to its commit, matching commit_exists's <sha>^{commit}. walk_unresolved_parents_walks_through_annotated_tag_of_commit still passes.

Why no existing test caught this

Every prior test builds a synthetic orphan commit to stand in for "we only have the tip". An orphan has no parents, so git_commit_parents was never once called on a commit whose parent was missing — the missing commit short-circuits earlier, at commit_exists.

The new test copies a real commit object into a repo lacking its parent, which is the state a clone is genuinely in after installing one bundle and before fetching the one below it. On the old implementation it fails with the exact production error:

called `Result::unwrap()` on an `Err` value: git rev-list --parents 1392069c... failed:
error: Could not read e57b6341...
fatal: Failed to traverse parents of commit 1392069c...

Also added: git_commit_parents against an absent parent, and the root-commit (no parents) case, which guards a parser that might mistake a header or the message body for a parent.

Testing

• New tests fail on the old implementation, pass on the new one. Full suite green, clippy -D warnings and fmt clean.
• E2E, live network: the repo whose clone reproduced this now clones clean — 4/4 commits, correct content.
• E2E regression: the 177-commit 96rknpy1GYhZ/freenet-stdlib demo, which exercises the tipped-bundle walk, clones identically to before the change (18 bundles downloaded, 5 dead-weight skipped, 190 commits).

[AI-assisted - Claude]

[sanity]

Review pass (Full tier: fetch/clone path)

Ran the lenses in-session and pushed the resulting coverage in c74b7b0.

Change-specific lens — git object format. This is now a parser for another program's output format, so I checked the real shapes against git cat-file commit before trusting any reasoning:

shape	risk	outcome
merge commit	multiple parent headers; dropping one loses a whole side of history	all returned, first-parent first — pinned
parent <sha> in the message body	parsing past the blank line invents a parent from prose	ignored — pinned, and verified the test fails if the break is removed
multi-line gpgsig	a blank line inside PGP armor could end header parsing early	armor blank line is stored as a single space, not empty; continuation lines start with a space so cannot match parent — pinned

One structural point that makes this safe in the direction that matters: parents always precede author/committer/gpgsig in a commit object, so stopping early cannot lose a parent. Only stopping late can invent one, and that is exactly what the blank-line break prevents.

Skeptical lens. The one deliberate behaviour change beyond the fix: a parent header whose sha is not 40 hex chars is now an error, where the old word-scanning loop silently skipped it. That is the sha-256 repo case, and freenet-git is sha-1 only throughout (CommitHash = [u8; 20], RefEntry.target: [u8; 20]). Previously such a repo would produce an empty parent list and a silently incomplete clone; now it fails loudly. Better, and unreachable for any repo that works today.

Testing lens. Mutation-checked rather than assumed: removing the header-only break fails git_commit_parents_ignores_parent_lines_in_the_commit_message; reverting to rev-list --parents fails both #60 regression tests with the exact production error.

Big-picture lens. Single caller (walk_unresolved_parents), whose surrounding logic is unchanged. No wire format, no contract, no signing. E2E on the live network confirms both directions: the repo that reproduced #60 now clones clean, and the 177-commit demo — which does exercise the tipped-bundle walk — clones byte-identically to before (18 bundles, 5 dead-weight skipped, 190 commits).

[AI-assisted - Claude]