feat!: configure with shipyard-cmake; the README no longer promises self-registration

[schmonz]

Do not merge until shipyard has landed bc3082a.

Part of the 14-repo shipyard-cmake flag day. After the cutover shipyard's pkg
postinstall no longer writes the CMake user package registry, nothing reads it,
and MavericksShipyardConfig.cmake refuses any cmake but shipyard-cmake.

The README was the point

README.md's "Building" section told developers:

install it once and it self-registers, so find_package finds it with no CMAKE_PREFIX_PATH

That is the mechanism being deleted. Left alone it does not merely go stale — it
instructs a reader to do something that produces an installation no cmake can
find. Rewritten to the post-cutover truth: install the shipyard pkg, which
provides shipyard-cmake, and configure with shipyard-cmake. The registry is
not described at all, because it will not exist.

Call sites

where	count	gate-visible?
.github/workflows/release.yml (configure + build, cross preset)	2	yes (check 18)
README.md — build recipe and both preset lines	4	no
tests/compat-sweep.sh, tests/differential.sh — by-hand run recipes	5	no
tests/README.md — the mutation-testing FIX instruction	1	no

2 of 12 are gate-visible. Check 18 reads workflow run: blocks plus
git ls-files -- '*.sh' minus tests/, and never opens a *.md, so the ten
instructions a human actually pastes are all invisible to it.

build/msc.sh

Replaced with shipyard's canonical scripts/templates/msc.sh, byte for byte
(blob 43c2af0, cmp clean). The old copy's second tier read
~/.cmake/packages/MavericksShipyard/ — check 16 flagged it, and it is the one
locator in this tree. The canonical template asks shipyard-cmake instead.
build/release-notes-file.sh sources it and uses $SHIPYARD, which the
template still exports.

Left alone deliberately

• docs/superpowers/plans/ and docs/superpowers/specs/ — dated records of
  completed work, including one that quotes the old msc.sh verbatim as part of
  its own history. Records, not instructions.
• tests/README.md:265 — a past-tense account of a stale-.o incident
  ("cmake --build after a one-line source edit produced IDENTICAL results").
  The FIX line below it, which is an instruction, was converted.
• find_package(MavericksShipyard REQUIRED) in CMakeLists.txt — still
  resolves, from inside shipyard-cmake's own prefix.

Verification

Conventions gate (check-family-conventions.sh from shipyard-cmake-collapsed),
run in a fresh clone:

• before: 5 failures — the release-notes one, plus check 16 (build/msc.sh
  reads the registry), check 17 (build/msc.sh is not canonical) and two check-18
  call sites.
• after: 1 failure, the release-notes one.

That single remaining failure is pre-existing and not from this PR: this
repo's conventions workflow is already red on main for "no workflow builds
the release body with the shared generator (release-notes.sh)". It is in the
flag-day baseline and is out of scope here.

Also green on the final tree: check-shell-portability.sh, check-comments.sh,
sh -n on every tracked *.sh, both workflows parse as YAML. Whole-tree sweeps
for check 18's regex, for a bare ( before a command, and for registry locators
are clean outside the historical docs/superpowers/ records.

No workflow step was added — install@v1's default mode already puts
shipyard-cmake on PATH.

Expected and not a defect: this PR's CI fails until shipyard lands, because
shipyard-cmake exists on no runner yet.

🤖 Generated with Claude Code

https://claude.ai/code/session_01GTxFde2TJMmp5p64DhvDSK