rebuild_f5.py: rerere never records a 'file location' (rename/add) conflict, so it re-triggers on every run nf-sib ← Beads

Twinned from https://github.com/cfsh/ninefold/issues/1027 by tools/beads/import_github.py's reconcile pass.

Hit while running ./tools/pr/rebuild_f5.py from the verdict-tier session (unrelated to that session's own chunk, #1025 — the conflict is entirely between two other open PRs).

Merging PR #1019 (feat/010-csharp-t2, co-locates C# tests / deletes tests/ dirs) against PR #1011 (explore: orbit-globe-terrain, which adds games/explore/tests/PlanetTerrainTests.cs in the old layout) produces:

CONFLICT (file location): games/explore/tests/PlanetTerrainTests.cs added in HEAD inside a directory that was renamed in origin/feat/010-csharp-t2, suggesting it should perhaps be moved to games/explore/PlanetTerrainTests.cs. CONFLICT (content): Merge conflict in tests/Ninefold.Tests.csproj

notes/f5.md documents the expected loop for an unrecorded conflict: resolve in the -f5 worktree, git add -A && git commit --no-edit (rerere records it), re-run — "it starts over and replays the resolution." That works for ordinary textual conflicts. It does not work here: I resolved this exact conflict (moved the new file to games/explore/PlanetTerrain.Test.cs, matching the new flat convention; kept both the new PlanetTerrain.cs compile-include and the new *.Test.cs glob in the csproj) and committed three times in a row, and git rerere status/git rerere diff showed nothing tracked each time -- every fresh rebuild_f5.py run hit the identical unresolved conflict again.

The csproj half never shows literal <<<<<<< markers (git's ort strategy auto-merges the text cleanly) but still flags UU, apparently because it's entangled with the directory-rename ambiguity on the neighbouring path -- and a conflict with no markers in the working tree is exactly the shape f5.md already says rerere can't record (documented today only for the delete/modify class, #465). This is the same non-recordable shape under a different git message ("file location" vs the delete/modify wording), and rebuild_f5.py's current error-classification doesn't recognise it as a droppable-branch case either -- so it just halts every time instead of auto-skipping like a delete/modify conflict does.

Filing unclaimed (not part of the chunk that surfaced it). Two shapes of fix, either is plausible: - Teach rebuild_f5.py to recognise this "file location" conflict message pattern and auto-drop the branch (like the delete/modify class already does), rather than halting for a manual resolution that can't stick. - Or find why rerere isn't recording the resolution (rerere.enabled=true, the shared rr-cache has plenty of entries) for this shape of conflict, and fix that so the documented "resolve once, it replays" promise actually holds here too.

Transient in one sense -- it self-resolves the moment #1011 or #1019 merges -- but until then it costs every session that runs rebuild_f5.py a fresh manual resolution.