fix(ci): authenticate the federated externals sync — for QUOTA, not for access (#1143)

[avrabe]

The federated-graph job has validated nothing since 2026-09-02

Sync externals (network — clones the 7 sibling repos)   failure
Validate the federated graph                            skipped
Non-vacuity guard — resolution must actually have run   skipped

error: IO error: git clone failed: Cloning into './.rivet/repos/gale'...
fatal: could not read Username for 'https://github.com': No such device or address

That error reads like a permissions failure and is not one

All seven siblings are public (gale, scry, loom, meld, kiln, jess, spar — all private=false), so an anonymous clone needs no credentials at all.

git only prompts for a username after the transport refuses it. GitHub returned a throttled response to an anonymous request, and on a tty-less runner the fallback to interactive auth surfaces as No such device or address.

The cause is a rate limiter on unauthenticated traffic, which bites hardest from datacenter address space — exactly where the self-hosted fleet lives. Timing fits: failures begin 2026-09-02, this repo's heaviest CI period. Independently corroborated — the same limiter hit unrelated infrastructure elsewhere in the same window, which is stronger than my inference from the log.

Fix: authenticate for quota, not access

GITHUB_TOKEN is repo-scoped and that's fine — we need the authenticated rate limit, not cross-repo permission. The url.insteadOf rewrite is applied inside the step and removed on exit rather than persisted on a shared self-hosted runner.

Two of my own claims are retracted

I said my v0.62 scoping commit broke this (a YAML commit cannot affect a git clone; the correlation was coincidental), and I told the org-wide review it was "standing-red on ~40 dangling traces-to" — that's my local rivet, a different version against a different cache. The job never reaches validation. Both came from describing a failure from memory instead of reading its step list.

What was right about the job, and stays

It is advisory, so nothing was blocked; and it fails closed — the non-vacuity guard is skipped rather than passing vacuously, which is the #1012 lesson working. What remains true is that an advisory job red on every commit since a release is indistinguishable from one that is merely noisy.

Same class as #1062: GitHub's own limits are the binding constraint, not our configuration.

Refs #1143, #1062

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!