scaffold-project.py re-run: a leg that gh sees and git cannot read gets a generic failure, and the reuse run's "two new legs" and private-leg text are wrong #542

scaffold-project.py: when git cannot read a leg that gh can see, the refusal is the generic a git or gh command failed instead of scaffold-remote-exists (#462's must-keep), because _held_seed runs for every non-empty leg (scaffold-project.py:431 at #506's head c6761db) and only_commit (:357-365) runs git ls-remote and git fetch --depth=1; run() does not set GIT_TERMINAL_PROMPT=0, so on a terminal git can stop for a username; and the depth-1 fetch downloads the leg's whole tip tree to read one commit. Direction: catch CommandFailed in _held_seed and return None; optionally --filter=tree:0. From the review of #506 (N1).
— #459, body

scaffold-project.py's visibility messages assume both legs were just created: "the two new legs inherit…" and "The two new legs are created…" (:918, :924 at c6761db), and _private_leg_note (:1078-1085) goes by the run's --visibility, so a re-run that reuses legs can print a NOTE that contradicts its own per-leg is reused and is public WARNING, and private reused legs under a public run get no private-leg note while project.yaml records the run's value. From the review of #506 (N2).
— #459, body