fix(hw-gate): merge past a generated-crate-map 409 instead of holding

[Kaden-Schutt]

Every rung of tonight's ladder hit the same 409 on the staging merge: crates/*/map.md carries a <!-- crate-map:generated --> block that both branches regenerate, so any two PRs touching the same crate conflict there while their real code merges cleanly.

#689, #690, #691, #686, #687, #688 and #682 all needed the same three manual steps — merge staging in, regenerate with scripts/check-crate-maps.py, merge. I did six of them by hand tonight. A gate that decides merge-staging and then holds on a generated file is asking a human to run a script, which is not review.

Change

On a 409 the decide phase retries locally: merge staging into the PR head, and if the conflicted set is generated maps only, re-run check-crate-maps.py for those crates, commit, and merge the result.

The retry is deliberately narrow, because auto-resolving conflicts is exactly where a gate can do damage:

• if any conflicted path is not a map.md, it declines and the hold stands with the offending paths named — a real code conflict must reach a human
• it regenerates rather than picking a side, so the committed block is what the tree actually generates, not whichever branch won
• a failed regeneration, a git error, or a timeout all decline rather than force

Test

test_generated_map_retry_refuses_real_code_conflicts builds a real git repo with a conflicting .rs and asserts the retry returns no merge SHA and names the file. The guard is the part worth pinning; the happy path is exercised by the ladder itself.

122/122 hw-gate tests pass.

Policy-floor by construction, so it cannot self-merge.