fix(data-deploy): build relaton-cli from git by default, not the gem

[andrew2net]

Flips data-deploy.yml's source input default from gem to git, so callers build relaton + relaton-cli from relaton/relaton@main instead of installing the released gem.

Why

No released relaton-cli has the index command — latest stable is 2.1.2 (2026-05-29), and even 3.0.0.pre.alpha.1 predates it. So the gem default cannot work: relaton index exits 0 printing Could not find command "index", nothing writes _site, and the run dies one step later at actions/upload-pages-artifact with tar: _site/: Cannot open. relaton-data-ids and -oasis have failed exactly that way every day since ~2026-06-09.

It also matches how relaton index is being worked on right now: iterating fast, without cutting a release per change.

Scope — smaller than it sounds

Only 14 of 32relaton-data-* repos have a caller at all, and 12 of those already pin source: git themselves. This changes behaviour for exactly two repos: ids and oasis.

Knock-on effects

• Those 12 pins are now redundant, so a cimas sync that drops them is the cleanup rather than the damage — removing the last thing that made syncing deploy.yml destructive. The synced template and spec/data_deploy_caller_template_spec.rb both claimed the opposite ("losing it fails loudly, so a sync can't wipe it unnoticed") and are corrected here — that file goes byte-for-byte into 29 repos, so the stale rationale would have propagated fleet-wide.
• relaton-cli-version is now inert on its own — it only applies to the gem path. Its description and a comment say so.
• relaton-ref deliberately stays main, not a known-good SHA (contra the trigger/concurrency hand-off's §3): bumping a pin per upstream change is the same treadmill as releasing. A broken upstream is not a broken site — deploy runs only on build success, so each repo keeps serving its last successful deployment.

Also in here

• Validate source input guard. Both paths are if:-gated, so an unrecognised value (typo, Git, stray space) silently skipped all of them and surfaced as the same misleading tar: _site/: Cannot open. Now it fails at the top of the job with a clear message. Value passed by env, per the file's own rule.
• Corrects the "~10 minute build" figure carried by seven comments across four files. Measured on relaton-data-3gpp (88,464 documents), run of 2026-08-12: 61 s to compile the frontend and resolve the bundle, 80 s for relaton index, ~3 min 10 s for the whole run; bipm and iana finish under two minutes.
• New data-index/README.adoc section on source, including the revert condition — flip back to gem when relaton v3 is stable, which is one line here plus a sync to drop the 12 pins.

Verification

bundle exec rake — 297 examples, 0 failures. New specs pin the default, assert both source paths still exist (by step name, so adding a gated step doesn't fail it while losing a path does), and cover the guard.

Before merging, two things

1. relaton-data-ids has never had a successful build. Its output scales to ~15 MB (3gpp's artifact is 7.9 MB for 88k docs) — nowhere near any Pages limit — and indexing should take ~150 s, but peak Ruby heap on 166,658 documents is unmeasured. A workflow_dispatch on ids before merge would settle it.
2. ids and oasis still carry the old caller template (push + pull_request), since the template change in 864dd69 hasn't been synced. After this, a PR on those two runs a full build and then skips deploy — the waste that commit removed. Landing the Cimas sync alongside closes it.

Out of scope, noted as follow-ups: no npm/bundler caching (61 s per build, now on every caller), and actions/configure-pages runs after the build, so a repo without Pages enabled burns a full build before failing (easc, gost today).