shape-doctor.py pin_restore: a shape copy renamed on BOTH sides of a merge leaves DD/AU/UA, and the doctor names neither new path and tells a person to keep "the hunks git merged" where there are none #783

Goal: a merge in which both sides renamed the same shape copy gets a conflicted-pin WHY that names both new paths. It never tells a person to keep hunks that do not exist.

Filed by lane openRepoShape-3 under v1.1.1, on Brett Heap's word of 2026-10-16T13:35:28Z ("yes create v1.1.1"). Lane 3's reviewer RV-b measured it while reviewing #781 (#753), as N2 (#781 (comment)). Main bf1f099b behaves the same, so it is not a regression.

What happens (git 2.43, default ort):

• The merge: ours renames the copy Makefile to a.mk and theirs renames it to b.mk.
• The index:
  • DD Makefile (stage 1 only);
  • AU b.mk, no stage 1;
  • UA a.mk, no stage 1.
• The doctor's conflicted-pin WHY:
  • it does not name a.mk or b.mk, because shape-doctor.py: a shape copy renamed on one side of a merge, conflicted under a name no pin has a row for, is named in a conflicted shape pin's why and left_for_a_person as renamed from that copy, for a person to settle, and never taken (#753) #781's rename rule keys on a path's stage-1 blob and neither has one;
  • for Makefile it gives the content sentence, "a person merges it by hand, keeping the hunks git merged", which is wrong for DD: git merged no hunks.

Fix:

• Treat a DD copy whose base blob reappears at two added paths (AU and UA, each with the base blob or an edit of it) as renamed twice. Name both paths for a person, with words that fit: choose one name, or keep both.
• Do not use the hunks sentence for a DD path.
• If the pairing cannot be proved from the index, at least name the AU/UA paths whose blob matches the base's copy.

Tests: in tests/test_doctor_pin_restore_merges.py, beside #781's test_a_copy_renamed_on_one_side_is_named_for_a_person:

• a both-sides rename;
• a both-sides rename with an edit on one side.

Lands after #781 (#753), which adds the rename rule.