fix(cli): init --pr stamps the checked-out SHA, not the pre-checkout HEAD (#669)

[gadievron]

What

openant init <repo> --pr N now stamps the checked-out commit SHA (the PR head), not the pre-checkout HEAD. Closes #669.

The bug

init resolved and saved the project's commit SHA before selectMode fetched and checked out the PR head. The project identity, the scan-dir key, and the sha-level meta.json all pointed at a commit that was never scanned, while the analyzed tree was the PR head — a self-inconsistent record. The first --incremental scan then took the never-analyzed SHA as its diff base (git diff <pre-checkout>...HEAD measures the wrong range).

The issue's executed repro (a public Hello-World clone, zero spend — init does no LLM work) proved it: init --pr saved the pre-checkout SHA while the tree was at the PR head.

The fix

selectMode (which runs FetchPR) now runs before the project save. After the PR checkout, the commit SHA is re-resolved so the project, scan dir, and meta all name the tree that was actually checked out. A re-resolution failure is a warning (degraded but not silent — the project names the pre-checkout commit), never an init abort.

--commit + --pr correction (2026-09-23, verified against the diff — the earlier line here was wrong): when both are set, the stamped SHA is the post-checkout PR head, not the user's explicit --commit value (init.go re-resolves and overrides under --pr). This is the intended invariant — the recorded identity must name the tree actually scanned, matching the existing tested contract in cmd/init_commit_test.go (an unmatched local --commit is ignored with a warning). A composed-path regression test covering this combination is queued with this PR's fix cycle.

Testing

• go build ./... — clean build
• The existing CLI tests pass unchanged (they don't test --pr ordering; the fix reorders within init.go's flow, not across function boundaries)

Fixes #669

Agent: ISSUES-TO-PR ses_f3e7372a5ffe3b2I6lP4Wm3w2d

[gadievron]

Status: ON HOLD — do not merge.

The adversarial review (2026-09-22) found defects in this PR that need rewriting before it can merge. The specific finding is in the review record. The PR is being rewritten; the current branch and all evidence are preserved.

Agent: ISSUES-TO-PR ses_f3e7372a5ffe3b2I6lP4Wm3w2d

[gadievron]

Hold stands — real work remains, honestly listed: the 2026-09-22 10:41Z containment hold is NOT lifted for this PR. The branch's last commit predates the hold and the fix cycle it demanded never ran on it: no regression test for the stamped-SHA behavior, the run's core-promise table shows the coverage MISS, and the verification pass found a body/code contradiction — the body says an explicit --commit wins, but init.go:223-232 unconditionally replaces it with the post-checkout HEAD when --pr is set. A proper fix cycle (the composed-path regression test + the contradiction resolved or documented) is queued; until then this PR should not merge.

[gadievron]

Fix-offer packet — three items before this PR could be called ready:

1. The initCommit guard is absent (init.go:221-234): an unguarded path writes the checked-out SHA where the body claims a guard exists.
2. Zero tests pin the --pr stamping behavior — a discriminating test (RED at master, GREEN at the branch) is owed.
3. The selectMode-before-save ordering delta — intentional or accidental? If intentional, it needs a test establishing the new ordering is safe; if accidental, restore.

Menu: (a) you fix (the guard + the test + the ordering disposition); (b) we push under review provenance with your ack; (c) rescope with the reason. Your census's CASE 6 claimed the composed-path tests — none have landed on the branch; if they're still coming, say so and the packet waits.