setup-project.py: its paste lines, the step (3), (4) and (7) checks, and the upstream-org guard #538

setup-project.py prints paths unquoted in two of its own paste lines.

• hand_over prints cd <clone> (setup-project.py:2169). <clone> is the absolute clone path under --into, or under the folder the run stands in.
• Step (7)'s backstop (setup-project.py (behind setup.sh and openRepoShape <Project>) checks the clone path <into>/<Project> only after all three repositories exist, so a person who follows README's "Rehearse first" and then runs for real in the same folder, where the rehearsal left ./Atlas, gets three new GitHub repositories, a refusal, a printed hand clone that fails on the same ./Atlas, and a re-run that is refused scaffold-remote-exists #498, :2023-2029) prints "finish by hand in <parent>:", then git clone --recurse-submodules <assembly> and cd <Project> && python3 scripts/bootstrap.py. Under --local-remote-dir, <assembly> is a filesystem path.
• A folder with a space anywhere on those paths, such as --into "/home/a b" or a Windows profile folder, gives a cd or git clone line that the shell splits.
• The project name itself is safe: by step (4) it has passed the naming policy (contracts/repository-naming.yaml:376, ^[A-Za-z][A-Za-z0-9]*$).
• family.py: init refuses to land in the standard's checkout and names a runnable scripts/family.py, printed commands quote paths, and add, bump and remove refuse the tracking branch and print their branch's push (#488, #486, #487) #507 (family.py and siblings.py print commands with unquoted paths, so under a folder with a space the member-git-dir-cached remedy's rm -rf would delete the wrong directory, and add's push line fails #486) quotes only the family lines, with the shell_word it adds to setup-project.py. The two lines above predate both family.py: init refuses to land in the standard's checkout and names a runnable scripts/family.py, printed commands quote paths, and add, bump and remove refuse the tracking branch and print their branch's push (#488, #486, #487) #507 and setup-project.py: the clone path <into>/<Project> is refused in step (3), before anything is created, when anything at all stands there, naming the path and telling a rehearsal's leftover clone apart as one to move or delete, and the plan names the clone path before the yes, so rehearsing and then running for real in the same folder - README's own order - no longer creates three repositories and then refuses with a hand clone that fails on the same directory (#498) #509; the bare cd %s was in hand_over before either.
• Possible fix: pass clone, parent and a path-valued <assembly> through shell_word. Add a test that runs setup with a space in --into and runs the printed lines.

— #459, comment

AT-scaffold N6: inside setup, the scaffold's own "NEXT STEPS: git clone / cd / make bootstrap" block (scaffold-project.py:1524-1536) prints before setup does those very steps itself.
— #459, body

A FILE standing where the clone's parent folder should be (<into>/<Family> with --family) passes step (3). All three remotes are then created, and the run dies with a FileExistsError traceback at setup-project.py:1974 instead of a REFUSED: line.
— #459, comment

With -- --dry-run passed through, step (7)'s refusal says "The three repositories WERE created" when none were.
— #459, comment

AT-scaffold N2: setup's step (4) never asks the naming validator about a --pin passed through after -- (check_names, setup-project.py:1523-1545 runs --explain <Project> <Project>-spec <Project>-code and nothing else), so the report says "no referent pin declared" and step (5)'s plan then says domain-descendant.
— #459, body

auS1-12: the upstream-org guard compares exactly: org == "opensoft" (setup-project.py:1280), and the origin check at :1243 does the same. So --org OpenSoft passes with no refusal, and since GitHub resolves an organisation login case-insensitively, a person with create rights scaffolds into opensoft's namespace. AGENTS.md:30-32 and README.md:336-338 say it refuses --org opensoft. The fix is to casefold the comparison.
— #459, comment

The step (7) recovery in --local-remote-dir mode prints a hand recursive clone without -c protocol.file.allow=always, which a clone of local legs needs.
— #459, comment

AT-scaffold N1: under --local-remote-dir the scaffold's own NEXT STEPS clone (scaffold-project.py:1524-1529) fails with transport 'file' not allowed, because setup adds -c protocol.file.allow=always for its own clone (setup-project.py:1692) and the printed line does not. Test path only.
— #459, body