Document a version-pinned install path for downstream apps (the catalog cannot select a Rivet version) #213

Context

We just migrated the first-party apps (fulcrum, taskly, syncpilot, benchpilot, brainfuel, podlens, autarx, pdfgist, regexmate, payback, flashpilot) onto the docs/ci.md standard: raco pkg install --auto --no-docs rivet from the Package Catalog plus the official setup-embed-racket action. That part works great — the catalog picked up v0.7.0 immediately and every repo now builds against the same released Rivet.

The gap

Apps that must hold back a Rivet revision (e.g. a native host not yet migrated to a codegen change) have no reproducible one-liner, because the catalog serves exactly one version and cannot select one. The docs' answer — link a checkout at a pinned revision — is heavyweight, and before this cleanup our repos had drifted into four different ad-hoc pin styles (a RIVET_COMMIT env + clone, a RIVET_PKG_SOURCE git URL with #sha, an actions/checkout ref, and a plain git-URL install). Each style also had to keep the setup-embed-racket action ref in sync by hand, which is exactly the coupling docs/ci.md warns about.

Suggestion

Document a tag-pinned git install as the standard hold-back form in docs/ci.md, e.g.:

raco pkg install --auto --no-docs https://github.com/turinglambdaai/rivet.git#v0.7.0

Verified today against the root multi-collection package: deps resolve exactly like the catalog install and rivet/distribution loads. That gives hold-back apps a standard pin form (and a story symmetric with pinning the action ref to the same tag).

Secondary motivation: the catalog tracks main, so between releases raco pkg install rivet can pick up unreleased commits once the catalog re-indexes (observed today: #207 merged after v0.7.0 while the catalog still served the release commit — fine right now, but the window exists). A documented pinned form is also the natural escape hatch for that.

Happy to send a PR for the ci.md paragraph if you agree with the direction.