feat(data-index): give relaton-data-ietf a Pages identity

[andrew2net]

Delivers the one live ask of HANDOFFS/relaton__support__ietf-index-config-and-cron.md: an ietf row in data-index/configs.yml.

Without a row, branding("relaton/relaton-data-ietf") falls back to a bare IETF Index with no favicon and no description, so the Pages site has no identity.

  - repo: ietf
    display: IETF
    source: index-v1.yaml
    branch: main
    favicon: 'https://www.ietf.org/static/img/ietf-logo.dc9646b3c716.svg'
    description: >-
      Bibliographic data for IETF RFCs, Internet-Drafts and RFC sub-series in
      Relaton format

Why the row is safe now

The hand-off said the row is only true once a crawl has run. The crawl has run. relaton-data-ietf@main carries a committed index-v1.yaml (177,230 records) from relaton/relaton-data-ietf@e2c19e4.

Two corrections to the hand-off

1. source is index-v1.yaml, not index-v2.yaml. relaton-ietf@main still declares INDEX1 = "index-v1" (lib/relaton_ietf/data_fetcher.rb:9). The index-v2 switch has not landed. It is a straight replacement, never both, so the flip waits for a crawl that commits index-v2.yaml.
2. No pubid_class. refactor(data-index): drop the retired Jekyll _config.yml machinery #74 removed the Jekyll _config.yml machinery, and spec/data_index_config_spec.rb now forbids that key on any row. The hand-off's proposed row would fail the suite.

What else moved

Six places encoded the "no ietf row" assumption. Five were in the hand-off's table; the sixth was not:

File	Change
spec/data_index_config_spec.rb	Row count 30 -> 31; ietf off the exclusion list. Also onto the overridden favicon roster — its own comment says adding a favicon: means adding it there.
spec/index_branding_spec.rb	Two examples asserted the fallback through relaton-data-ietf. They now use relaton-data-sdo, which appears in neither configs.yml nor cimas.yml.
spec/cimas_data_pages_spec.rb	excluded is now empty. Every repo Cimas syncs deploy.yml into has a row.
lib/data_index_config.rb	The two comments naming ietf as the reason #branding never raises.
data-index/README.adoc	Row count and status section.

The fallback keeps its guard rather than being deleted: no live repo exercises it any more, but a repo added to cimas.yml before its row lands must still resolve rather than fail its own Pages build.

Also corrects counts that were already stale before this PR: Cimas syncs deploy.yml into 31 repos, not 30, and the fleet branch split is 23 on v2 and eight on main — no repo is on master since #71 moved relaton-data-ietf. The comment claimed "23 of the 30 are on v2, six on main, one on master".

Verification

Check	Result
bundle exec rspec	326 examples, 0 failures (baseline 321; +5 are the per-repo cimas_data_pages_spec examples that now run for ietf)
bin/index-branding relaton/relaton-data-ietf	IETF Index + IETF favicon + description
bin/check-data-pages --list	31 repos, ietf present
bin/check-data-pages --raw-only ietf	200
bin/check-data-pages --site-only ietf	Not verified locally — see below

The site check could not run in my sandbox: relaton.github.io is blocked there, and it errors for every repo, including known-live iso and ids. Please confirm https://relaton.github.io/relaton-data-ietf/ returns 200 before merging. A 404 means Pages is not enabled on that repo — a relaton-data-ietf settings task, not a fault here.

Relation to #72

#72 also adds an ietf row, but bundles the relaton/relaton#113 machine-index flags and is stale against main: it re-adds pubid_class, restores data-index/generated/, and derives pubid_flavor from a private helper 257dd77 deleted. It also depends on relaton/relaton#114.

This PR is deliberately the Pages identity alone. #72's flag wiring still needs a re-cut against main once relaton/relaton#114 lands.

Not in scope

• Fleet drift check (hand-off §1 advisory). Nothing asserts that each of the 28 repos mapping crawler.yml really carries the permissions: contents: write block it was synced. spec/workflow_permissions_spec.rb sweeps the ~7 distinct templates and spec/data_deploy_caller_template_spec.rb pins the crawler grant on the template object — both dedupe the mapping away. Closing it means reading files in 28 other repos over gh api, so it is a new script, not a spec.
• Retiring the rfcs / rfcsubseries / ids rows. Every released relaton reads index-v1 from those three. Blocked on relaton's Ietf::Scraper moving to the combined index.
• Flipping source to index-v2.yaml. Blocked on the DataFetcher switch and a crawl that emits it.

The hand-off's crawler.yml items need nothing here: the un-map ask is withdrawn, and the missing permissions: contents: write was fixed in the other repo (relaton/relaton-data-ietf@7ca6170). Its "cimas.yml pins ietf to master" correction is already applied — cimas.yml:281 reads branch: main.