Alert when a daily build stops producing artifacts

A daily build that stops producing artifacts stays green, so nobody finds out. Two real cases:

- **llvmflang** failed for ~2 months (60 consecutive runs) before anyone noticed.
- **clang_ir** has reported success every day since **February** while building nothing, because its activity gate watched `llvm/clangir`, archived on 2026-02-21. Six months of a stale compiler on the site. Fixed in #80, found by accident.

The naive version of this alert ("no successful build in N days") is too noisy to live with: a gated fork that is genuinely idle is *supposed* to skip for weeks, and may legitimately wake up later. We do not want to be paged about a dormant-but-healthy fork.

The fix is to alert on the **discrepancy**, not the silence. Three rules, each with a decisive signal rather than a heuristic:

- [ ] **Upstream moved but we did not build.** `repos:` has commits newer than `last_success` by more than N days. Catches a fork whose build breaks while its upstream is active. An idle fork never trips this, which is what kills the noise.
- [ ] **The gate can never fire.** A `repos:` target is archived or 404s. Catches `clang_ir`; the activity rule above would *not* have, since the dead repo has no commits by definition.
- [ ] **Ungated builds must always produce.** An entry with no `repos:` key (`clang`, `clang_assertions`, `clang_llvmflang`) builds unconditionally, so no successful build in N days is unambiguously broken. Catches the llvmflang case.

The data is already there: `https://lambda.compiler-explorer.com/compiler-build/` returns `last_success.timestamp`, which is what `build-status.md` badges render. `clang_ir` currently returns `2026-02-22`. So this needs `compilers.yaml` plus that endpoint plus the GitHub API, and no new build-side plumbing.

Worth deciding separately: where it reports (a scheduled workflow that opens or updates a single issue is probably enough, and is self-throttling).

Start with compilers.yaml and the compiler-build/ endpoint, which exposes last_success.timestamp, then review the GitHub API needed to inspect repository activity and status. Done means detecting all three discrepancies without flagging legitimately idle gated forks, with reporting handled by an agreed scheduled workflow that opens or updates one issue.

Written by the indexing model from the issue text.