caller-pins: read callers from raw, and never trust the session sentinel

[bdelanghe]

Follow-up to #19. The first live census (run 30860781598) failed two ways — and both are worth reading, because in each case a guard is the only reason we found out.

1. Rate limit — the census truncated itself and still looked confident

Unauthenticated api.github.com allows 60 requests/hour. The census makes one call per repo (~90 for this org), so it took 23 consecutive HTTP 403s and still printed:

FDS-PINS-RESULT {"callers":43,"current":13,"behind":30,"unknown":0,"errors":23}

callers: 43 reads like a census. It is a census of whichever repos sorted alphabetically before the budget ran out. The run failed only because unreadable repos raise rather than being treated as "no caller" — had fetch_caller swallowed non-404s, this would have been a green run reporting a truncated fleet, which is precisely the failure the whole lane exists to catch, reproduced inside the lane itself on its first outing.

Authenticating is not the fix. github.token is scoped to this repo and cannot read another repo's contents at all — it would have made the census smaller, not larger. Callers now come from raw.githubusercontent: a CDN, unmetered against that 60/hour budget, no credential. The org listing stays on the API because it has no raw equivalent, but that is one call rather than ninety.

2. The session sentinel — every file 404'd, which looks exactly like "no callers"

A cloud session's GH_TOKEN is the literal string proxy-injected — set, non-empty, and not a credential; the real one is injected at the egress proxy. The tool forwarded it as Authorization: Bearer proxy-injected, and raw 404s every file under a bad bearer. A 404 means "not a caller", so the census came back empty:

FDS-PINS-RESULT {"callers":0,...}
::error::found ZERO callers — refusing to report success on an empty census

The empty-census guard is the only reason this surfaced instead of being read as "the fleet has no callers." real_token() now treats the sentinel as absent.

3. Private repos are skipped and counted, not attempted

Without a credential a private repo 404s on raw — indistinguishable from having no caller. They are now excluded up front and reported as unexamined_private, rather than silently folded into the 404 path.

Verified

✗ brand 62990dd  ✗ drift-gate 62990dd  ✗ guest-room 8b7d8a8  ✗ site 62990dd
✓ frond 162accb  ✓ front-desk-scheduler 162accb  ✓ lobby 162accb
FDS-PINS-RESULT {"callers":7,"current":3,"behind":4,"unknown":0,"unexamined_private":0,"errors":0,"authenticated":false}

authenticated: false from a session that has GH_TOKEN set is the sentinel fix working. 20 tests pass (4 new for real_token, 2 for caller_url).

Worth noting from the partial data

Even truncated, the first run corrected my picture: 13 of 43 callers were already current. The fleet is split by when a repo adopted — the 2026-07-30 wave sits at 62990dd, later adopters came in at 162accb. So the re-pin backlog is smaller than "~44", and gh-action-brand-checks / -contracts / -node-uniqueness now have callers despite being recorded as empty repos in #2. The full number lands with the next clean dispatch.

🤖 Generated with Claude Code

https://claude.ai/code/session_017RMKHpGXzw9Zkv49fzVssg

---

Generated by Claude Code