Fix nil-pointer panic in checkpoint parent-load error path

[Soph]

Problem

In FirstParentChainStoppingAt (internal/planner/checkpoint.go):

commit, err = object.GetCommit(store, parent)
if err != nil {
    return nil, fmt.Errorf("load parent commit %s: %w", commit.ParentHashes[0], err)
}

On error, object.GetCommit returns a nil commit, so commit.ParentHashes[0] is a guaranteed nil-pointer dereference panic — and even if it didn't panic it would print the wrong hash. Only reachable through the exported planner API, which is why it hadn't fired.

Fix

Reference the parent hash we just tried to load. The two sibling GetCommit sites in the same file already use the correct (input) hash in their messages, so this brings the error path in line.

Tests

TestFirstParentChainStoppingAtMissingParentErrors seeds a commit whose first parent is absent from the store and asserts the call returns an error naming the missing parent (rather than panicking).

🤖 Generated with Claude Code

---

Note

Low Risk
Single-line error-path fix in planner checkpoint walking with a focused regression test; no behavior change on success paths.

Overview
Fixes a bug in FirstParentChainStoppingAt where loading a missing first-parent commit could panic instead of returning an error.

On GetCommit failure the code formatted the error with commit.ParentHashes[0], but the failed call leaves commit nil. The message now uses the parent hash that was just requested, matching the other error paths in the same file.

Adds TestFirstParentChainStoppingAtMissingParentErrors, which seeds a tip whose first parent is absent from the store and checks the returned error names that parent (and does not panic).

^{Reviewed by Cursor Bugbot for commit 43a0631. Configure here.}