shape-doctor.py pin_restore: a shape copy renamed on one side of a merge conflicts under its new name, which no pin's row lists, so the why never names it and only the merge row does #753

Goal: a conflicted file that is a shape copy under its old name is named in pin_restore's why and its left_for_a_person, as #736 does for copies only the other side's pin lists. The reader then learns it is a copy and that a person settles it.

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 found it while reviewing #736 (#687). It is not a regression: main does the same. It is the same family as #687.

What happens. RV-b measured this on main 66b230ed and on #736:

• Ours renamed the Makefile to build.mk and theirs edited the Makefile.
• The merge conflicts at build.mk, which no pin's row lists.
• The why and left_for_a_person leave it out. Only the merge row lists the unmerged path.

What to do:

• Where a conflicted path's stages came from a rename of a path some side's pin lists, name it with the old path ("build.mk, renamed from the copy Makefile") and give it to a person. Never take it whole.
• git's rename detection over the stage entries, or the merge's own rename record, can find the old path.
• Test it with the rename on each side.

Lands after: #736.