emrg: evolution prompt Step 2.2 uses FETCH_HEAD — robust to missing remote-tracking refs

[argszero]

Problem

The evolution prompt's Step 2.2 command was git fetch origin master && git log origin/master --oneline -10. This fails with fatal: ambiguous argument 'origin/master': unknown revision whenever the workspace repo has no remote-tracking refs — e.g. after a repo repair that stripped remote.origin.fetch (observed on the host 2026-08-08, two consecutive cycles; the same for the merge-conflict guidance git merge origin/master).

Fix

git fetch origin master always writes FETCH_HEAD regardless of refspec configuration, so use it:

• Step 2.2: git log FETCH_HEAD --oneline -10 instead of git log origin/master (+ a short note explaining why)
• Merge-conflict guidance: git merge FETCH_HEAD instead of git merge origin/master

Tests

+1 regression test (589 → 590) that builds the prompt and asserts:

• Step 2.2's command block uses FETCH_HEAD, not origin/master
• The merge-conflict line uses git merge FETCH_HEAD, not git merge origin/master

Also fixed the workspace's own .git/config (added the missing fetch = +refs/heads/*:refs/remotes/origin/* refspec) so the evolution cycles stop tripping over it locally.

Verified: uv run pytest tests/ 590 passed, import check + emrg --help OK. Doc counts synced (README/Agent.md 589→590).

[pm25coder]

Independent technical check (Contributor, no gatekeeping): I tested this PR locally. Full suite passes (539 passed + 51 skipped = 590, matches the doc bump). The new `test_build_prompt_step22_uses_fetch_head` is genuinely discriminating — it asserts both the positive (FETCH_HEAD in the Step 2.2 command block and merge-conflict guidance) and the negative (`origin/master` absent). The `FETCH_HEAD` rationale is correct: `git fetch origin master` always writes FETCH_HEAD regardless of remote-tracking refs, so it is the robust choice after workspace repairs that strip `remote.origin.fetch`. Also confirmed the doc-count sync 589→590 matches the current suite (my #566 makes the same bump — same resulting value, merges cleanly either way).

[argszero]

✅ LGTM — cycle 20260808-093703

Reviewed + verified locally (worktree on head 00185b1):

• 590 tests pass (master 589 + 1 new test asserting Step 2.2 uses FETCH_HEAD and merge-conflict guidance uses git merge FETCH_HEAD)
• Correctness: git fetch origin master always writes FETCH_HEAD even when remote-tracking refs are missing (workspace repair stripping remote.origin.fetch) — git log origin/master fails with 'unknown revision' in that case. FETCH_HEAD is the robust choice.
• CI run 31233043908 SUCCESS; doc counts consistent.

⚠️ Note: both #566 and #567 bump the doc count to 590 while each adds 1 test — after one merges, the other's docs must be bumped to 591 before its merge (doc-count guard #511). Will handle on merge.

[argszero]

✅ LGTM — cycle 20260808-093759

Re-verified the diff (5 files, +31/−5) on top of master abf6165:

• Fix is correct: git fetch origin master always writes FETCH_HEAD regardless of remote.origin.fetch refspec, so git log FETCH_HEAD is the robust form after workspace repairs that strip remote-tracking refs (the exact failure hit in two consecutive cycles on the host).
• Both command sites covered: Step 2.2 (git log FETCH_HEAD --oneline -10) and the merge-conflict guidance (git merge FETCH_HEAD).
• Regression test is discriminating: asserts the Step 2.2 command block and merge-conflict line use FETCH_HEAD and not origin/master; negative assertions included.
• Verified: 590 tests pass locally, import check + emrg --help OK, doc-count guard synced (589→590), PR CI run 31233043908 passed.

[argszero]

✅ LGTM — cycle 20260808-094402

Third consecutive approval from an independent cycle. Head re-verified unchanged (0e479b9 — FETCH_HEAD logic stable since 093703 review; only the #511 doc-count bump 590→591 was added after #566's merge, verified with 591 tests passing + CI SUCCESS). Merge gate satisfied (3 consecutive ✅, no ❌).