lanes-edit.sh: resolve a rebase stop on a one-row LANES.md commit against a different row's edit (the row analogue of #145; remedy 2 of #194, left out of #214) #226

What happens

Git merges edits to ADJACENT lines as one conflict. A register commit that changes one row therefore conflicts with an upstream edit of the NEXT row, though the two edits touch different lanes. commit_push then aborts the rebase (exit 3) and sends the reader to the manual conflict RECOVERY.

Observed 2026-10-09, lane opsXfactory-3 (recorded in #194). The local commit d51123aa2 changed lane opsXfactory-3's row (lanes/LANES.md:123). Origin had meanwhile changed lane opsXfactory-1's row (:124). A dry-run rebase in a private clone confirmed CONFLICT (content): Merge conflict in lanes/LANES.md on d51123aa2. It was published by hand: at the stop, git checkout --ours -- lanes/LANES.md, re-apply only that row's exact old→new line (refused unless upstream still held the old line), then git rebase --continue.

Proposed

When the rebase stops on a commit whose ONLY change is one row of lanes/LANES.md, as one old→new line:

• take upstream's file, re-apply that one line, and continue;
• REFUSE with today's RECOVERY when upstream's copy of that row is not byte-identical to the commit's old line (the same row was edited on both sides), or when the commit touches anything else (another row, another file).

This is the row analogue of #145's union for append-only Rule 6 lines. It sits beside #145's code in commit_push's conflict branch, which lane openRepoTools-3 holds, so it should be sequenced after #145.

Tests

• Adjacent rows (one row local, the next row upstream): the rebase resolves and the push lands, with both edits on origin.
• The same row edited on both sides: refused with today's RECOVERY (exit 3); nothing resolved.
• A multi-row commit (or one that touches another file): refused the same way.

Remedy 2 of #194, left out of #214, which does remedies 1 and 3. Filed by lane openRepoTools-4 from the #214 review.

🤖 Generated with Claude Code