CI: single-source the rainix flake-pin sha instead of repeating it across reusables

[thedavidmeister]

Problem

After #245 + #247, every reusable workflow pins its rainix flake refs to an explicit commit sha — nix develop github:rainlanguage/rainix/<sha>#<devshell> — to dodge GitHub's burst rate-limit 429 on HEAD resolution (api.github.com/.../commits/HEAD). That fix is correct, but the sha is now hardcoded in ~35 places across 11 reusable workflows.

This is a multiple-sources-of-truth hazard:

• Bumping the toolchain means a find-replace across every .github/workflows/rainix-*.yaml.
• A missed occurrence silently leaves one reusable on a stale sha (or, if reverted to bare github:rainlanguage/rainix#…, back on the 429-prone HEAD path) — and nothing fails loudly.

Goal

Single-source the pin sha so a toolchain bump is a one-line change, and drift is impossible (or at least caught).

Options to weigh (not prescriptive)

1. One env var → all refs. Define the ref once (e.g. a workflow-level env: RAINIX_FLAKE: github:rainlanguage/rainix/<sha>) and use nix develop "$RAINIX_FLAKE#<devshell>" everywhere. Still per-file env, but one value per file instead of N.
2. Generated workflows. Keep the sha in a single source file and codegen the rainix-*.yaml refs from it, with a CI check that regen-and-diff is clean.
3. Nix-side indirection. A flake registry override / pinned input so consumers reference a name that resolves to the pinned rev from one place.
4. Cheap guard (minimum). Even without full DRY, a CI/pre-commit check that asserts all flake refs across the reusables share exactly one sha (and none are bare/unpinned) catches drift loudly.

Constraints

• Must NOT reintroduce a bare unpinned github:rainlanguage/rainix#… ref (that's the 429 this all exists to avoid).
• Bumping should remain obvious and reviewable.

Context: the pin convention is documented under ## CI → "Flake-ref pinning in reusable workflows" in CLAUDE.md (added in #247).