Repair duplicate rows left by concurrent bot merges

[sr320]

main has been failing scripts/validate.py with 7 duplicate-id errors. This repairs the data. It does not yet fix the workflow gap that caused it — see the note at the bottom.

Two causes, both from concurrent inv/* branches

1. Verification stamps merged as added lines instead of in-place edits

PRs #52 and #53 were each cut from the same base and stamped a verification. Git kept both the old and the new version of every row they touched:

itm-00041,Pipet parts,consumable,209-CAB-15,...,unverified,2021-08-29,,      <- stale
itm-00041,Pipet parts,consumable,209-CAB-15,...,present,2026-08-06,maddybernstein

Affects itm-00041–itm-00044 and locations 209-CAB-15, 209-CAB-16. Kept the stamped copy, dropped the stale one.

2. itm-00500 was allocated twice

next_item_id() in scripts/apply_issue.py is max+1 over the branch's own copy of items.csv, so two adds branched from one base picked the same id for different items:

PR	item	merged	resolution
#51	Glass bottles → 209-CAB-14	20:06	keeps itm-00500
#59	10 loop needle → 209-CAB-16	22:30	becomes itm-00501

First merge keeps the id; the later one takes the next, which is what the allocator would have produced had it seen the merged file.

This also restores item_id / location_id sort order — both files held it everywhere except at these two damage points.

Verification

items      505 -> 501 rows
locations  175 -> 173 rows
ids unique: True    sorted: True    header unchanged: True
ids removed: none   ids added: itm-00501 only
rows not byte-identical to a pre-existing row: itm-00501 only
validate.py: validation passed (exit 0)

Files are CRLF; I confirmed a byte-identical CSV round-trip before editing, so the rewrite introduces no formatting churn. The diff is 3 insertions / 9 deletions.

Follow-ups, not in this PR

• Verify 209-CAB-48 (1 items) #70 will recreate this damage and should be closed rather than merged — its diff re-adds itm-00114–itm-00122 and 209-CAB-48/49, which already exist on main, and re-adds some of them with stale pre-verification values. Issue Verify a location #65 can regenerate it against a fixed main.
• Nothing validates at merge time. As the comment in issue-to-pr.yml notes, a PR opened with GITHUB_TOKEN doesn't trigger validate.yml, so validation runs before the PR exists and never again. A stale branch can therefore merge dirty — which is exactly what happened here. Worth closing before any bulk retrigger of the ~29 issues that never got PRs.

🤖 Generated with Claude Code