refactor(data-index): drop the retired Jekyll _config.yml machinery

[andrew2net]

Why

support#58 (relaton/relaton#83) replaced the Jekyll Pages build with relaton index, which reads each data repo's own data/ folder. The generator, its committed snapshot and the keys that fed them have had no consumer since — data-index/README.adoc already listed retiring them as follow-up work.

Two measurements settle the scope:

1. The snapshot never reached a target.gh api repos/relaton/relaton-data-<r>/contents/_config.yml returns 404 for all 30 repos in configs.yml. None has ever carried a committed _config.yml, and cimas-config/ maps none either.
2. source and branch are still live.DataIndexConfig#raw_index_url joins baseurl + source, and bin/check-data-pages requires a 200 from it. branch is additionally cross-checked against cimas.yml by spec/cimas_data_pages_spec.rb. Both stay.

What changed

Removed

• bin/gen-data-index-config and the 30-file data-index/generated/ snapshot
• spec/generated_configs_spec.rb, its drift guard
• DataIndexConfig#render / #render_repo and the private pubid_class, pubid_require, sq
• the paginate and pubid_require defaults, and every row's pubid_class

configs.yml now carries only what its two live consumers read — bin/index-branding (branding for the Pages build) and bin/check-data-pages (the 200 gate):

 - { repo: ccsds, display: CCSDS, source: index-v2.yaml, branch: v2 }

Specs move onto that public surface (#branding, #raw_index_url). A new guard block keeps the removed keys from creeping back in dead. The one example in spec/index_branding_spec.rb that cross-checked #branding against the renderer goes with it — there is nothing left to drift against.

The old pubid_class values stay in git history; the live ones are in each flavor's lib/relaton/<flavor>/data_fetcher.rb in relaton/relaton.

Also: iana points at index-v2

This delivers the remaining half of relaton__support__iana-index-v2-config.md. Its pubid_class and regenerate-the-snapshot asks are retired by the removal above; this is the source: ask.

Relaton::Iana::INDEXFILE is index-v2 in relaton/relaton@main, so the row names index-v2 too.

Warning

relaton-data-iana@v2 has not published it yet (measured 2026-08-22: index-v2.yaml and index-v2.zip both 404, index-v1.yaml is 200). This is the one row whose source leads its data repo's publish, so bin/check-data-pages reports a known 404 for iana until that repo's crawler emits index-v2. Any other repo's non-200 is a real regression.

Nothing automated is affected: no workflow runs that script, no spec makes a live request, and data-deploy.yml reads only branding from configs.yml. The expected failure is called out in configs.yml, data-index/README.adoc and the script's own header, so an operator can tell it apart from a regression.

Verification

• bundle exec rake — 321 examples, 0 failures
• bin/index-branding output byte-identical for iana, w3c (which loses a pubid_require override) and ietf (the no-row fallback path)
• bin/check-data-pages ccsds iso --raw-only → 200; iana → the expected 404
• asciidoctor parses both README.adoc files clean
• No rubocop config exists in this repo, so rubocop was not run

Notes

• Reviewed by the code-reviewer agent: no lost coverage, no orphaned private methods, no stale reference that reads as current, balanced AsciiDoc blocks, valid 30-row configs.yml.
• Pre-existing and untouched: bin/index-branding:13 says Cimas copies deploy.yml "for 29 repos", but the data group in cimas.yml holds 31 entries.