adopt-project.py under LC_ALL=C PYTHONUTF8=0: the --description em dash, plan's git grep and check's submodule url still end in a UnicodeEncodeError before any leg #653

Lane: openreposhape-1 (openRepoShape-1)

Under LC_ALL=C PYTHONUTF8=0, execute, plan and check should hand git and gh the exact bytes, as #614 did for git rm, so that the three places below no longer end in a UnicodeEncodeError before any leg exists.

From lane 1's triage of 2026-10-15, D4, approved by Brett Heap at 2026-10-16T11:21:17Z ("Approve all (Recommended)"). One pull request covers the lines below.

Parent: #457. Milestone: v1.1.0.

Lands after:

• adopt-project.py: a kept submodule url on this disk where git ls-remote reaches no repository is a finding execute refuses before any leg, so it no longer ends adoption verified over a recursive clone that fails (#418) #618, which edits the code around _resolved (_resolution_of and _relative_url_findings);
• lane 2's adopt-project.py: the read-across follow-up names legs.code_path and legs.spec_path and no path, and the contracts/ rule's reason names none, so the hand edit of a leg's mount the tool asks for leaves no plan-time path in check, the split commit or the pull request (#600) #628, which edits cross_leg_references.

Effort: S. Platform: Linux, macOS (the same locale case as #527).

Lane openRepoShape-1 claims it at filing; see its CLAIMED comment.

Brett Heap's answer to the triage's question, whether the C locale is in scope (2026-10-16T11:21:17Z): "In scope, file D4 (Recommended)".

Why this is in scope. By the bar these are backlog: #457's body counts the C locale as exotic, and all three stop before anything exists. But Brett Heap's ruling of 2026-10-12 for #527 ("pass git the exact bytes the tree holds, under any locale") put this locale in scope for execute. Under it, a GitHub-mode execute stops at gh repo create (adopt-project.py:7824-7827, read on 396c0ff) and never reaches #614's fix. This issue is the S follow-up that reuses #614's bytes helper.

Lines

• L1-33 (P2 only because the C locale is in scope): under LC_ALL=C PYTHONUTF8=0, every GitHub-mode execute dies with a UnicodeEncodeError at the first gh repo create, before any leg and even for an all-ASCII source, because of the em dash in --description; gh pr create --body then carries the moved paths (from the code, not run). Where: adopt-project.py:7824-7827 on 396c0ff. Read again on 7ba64f0: the em dash is still in _create_leg_remote's --description (:8623-8627). The line measured it on 39da3ad, the same on main. (source)
• L1-34 (P2 only because the C locale is in scope): under that locale plan's cross_leg_references hands git grep a non-ASCII spec directory or code entry as text (Übersicht/), so plan gives a traceback and no plan. On 396c0ff, read: the git grep arguments are text. Read again on 7ba64f0: cross_leg_references still passes spec_dir and code_paths as str. The line measured it on 39da3ad, the same on main. (source)
• L1-35 (P2 only because the C locale is in scope): under that locale _resolved hands git config a non-ASCII relative submodule url (../Ünterlagen) as text, so check and execute die with a traceback before any leg. On 396c0ff, read: _resolved. Read again on 7ba64f0: unchanged. The line measured it on 39da3ad, the same on main. (source)

Rides along (backlog; tick it here if the same change covers it)

• L1-36: cosmetic. Under the C locale plan's table pads a name before escaping it, so café.md and caf\xe9.md shift the leg column. Where: adopt-project.py:3933 on 396c0ff. The line measured it on 39da3ad. (source)
• L1-38: macOS NFD names (core.precomposeunicode) and a Latin-1 locale are not measured for L1-33 to L1-35; the review container had no locale sources. Never measured, so not re-checked. (source)

Each line above is a line of #457's checklist comment (issuecomment-6200110061). Tick it there too when this closes.