Both skills said to derive the main clone from the checkout without saying
how, and dsh-upgrade names dsh-customize as the owner of checkout discovery
— so the technique belonged there and was missing.
dsh-customize now gives it: `git rev-parse --git-common-dir` from the
checkout yields the shared git directory, whose parent is the main clone.
It also names the two ways to get this wrong — the answer is relative for a
plain clone, and paths must be compared physically, since macOS reaches
/var through a symlink to /private/var.
dsh-upgrade links to that procedure rather than restating it.
Verified against both shapes: an adopted clone outside the container, and a
curl-shaped install whose clone is at <source>/master.
"Master clone" named the repository after a branch it need not be on. An
adopted clone keeps whatever branch it had — verified: adopting a clone
checked out on a feature branch leaves it there — so the name was wrong for
every install that did not come from curl.
Renamed to "main clone" in dsh-upgrade and dsh-customize, describing its
actual role: the one real clone whose object store every worktree shares.
dsh-upgrade also now says not to assume the main clone sits on `master` or
that its `origin` is authoritative upstream, since an adopted clone may
point at a fork. The fetch itself was already correct: step 1 resolves
authoritative upstream separately, and step 4 fetches upstream `master`
from it rather than from the clone's own branch.
Adoption installs the master wherever the adopted clone already is, so
dsh-upgrade and dsh-customize can no longer state <source>/master as fact.
Both skills already derive the master from the launcher, so the procedures
hold; only the layout description was wrong. dsh-upgrade now names
`git rev-parse --git-common-dir` as the way to resolve it.
The legacy-migration clauses stay: installs made before this change can
still link PATH straight at a worktree.
Turtle