ci: run the four example tours, so "runnable" is measured (#20)

[EricAndrechek]

Closes #20.

README.md advertises examples/ as "four side-by-side runnable tours" and nothing ran them. examples/chplay.sh existed to do exactly that, and nothing called it — so a signature change in any binding would have broken its tour with every gate green.

This takes option 2 from the issue: run them, scoped to the artifacts job, the only job with a verified artifact already in hand and all four toolchains already set up. The marginal cost is one step rather than a new job.

Two flags, both load-bearing

flag	without it
--require-all	chplay skips a missing toolchain, so a CI run where all four skipped exits 0 and proves nothing
--locked	an unlocked resolve silently rewrites a drifted lockfile and exits 0 — and on a runner that rewrite is discarded, so the drift passes forever

Interactively a skip is still the right answer; you should not need four toolchains to see one tour. Neither flag changes what a tour prints.

Both guards were verified by breaking them, not by inspection

# every toolchain hidden (PATH=/usr/bin:/bin)
chplay.sh                 -> exit 0, four SKIPPED      <- the vacuous pass
chplay.sh --require-all   -> exit 1, four FAILED

# chtypes 0.1.0 planted back into examples/rust/Cargo.lock
chplay.sh rust --locked   -> exit 1  (cargo refuses to update the lock)
cargo check (unlocked)    -> exit 0  AND rewrote the lock to 0.1.2

It found a real defect on its first run

examples/python/uv.lock recorded chtypes 0.1.0 — it had missed the 0.1.1 and 0.1.2 releases. #20 only knew about examples/rust/Cargo.lock, which had been patched by hand; this one was never caught because nothing ever resolved it. Regenerated here. All four tours now run 16/16 sections.

RELEASING.md

Two additions, the second unrelated to #20 but found while writing the first:

1. The lockfile-regeneration step, since CI now fails on a stale one. That is deliberate — it makes the missed-lockfile failure mode impossible rather than relying on someone remembering.
2. The release order for every release after the first. The file documented only the one-time launch order, which puts Go first. For a routine release Go must be last: a Go module publishes by the tag existing on a public repo, and release-go.yml only verifies — confirmed by reading it, it runs go build, go vet and verify-published.sh and has no publish step — so that push is irreversible with no gate in front of it.

Safety

No job name: changed; branch protection keys required checks on those, and renaming one would silently drop it from the list.

🤖 Generated with Claude Code

https://claude.ai/code/session_018ckJDLjWhAAttQVrYnQEJD