The toolchain currency report cannot distinguish an accepted pin lag from a new one

[jakewan]

Context

Surfaced while bumping the Go toolchain in #33, which landed at 1.26.7 rather than at the current release for the reasons tracked in #32. That deferral is deliberate and recorded — but the weekly report has no way to say so.

Problem

The Toolchain currency workflow fails whenever any pin trails upstream, and that failure is the entire signal. SECURITY.md § Build and CI supply chain records why: the deliberate failure is what surfaces the report at all, since mise outdated exits 0 whether or not a pin has moved, and no update bot covers mise.toml, so this report is the only review mechanism those pins have.

The report carries one bit of state — behind, or not. It cannot express behind, known, accepted, and tracked. So a deliberate deferral makes it red every week for a reason already decided, and while it stays red for that reason a genuinely new lagging pin arrives inside the same red and is indistinguishable from it.

The cost is not the noise. The report's value depends on a human reading a red run, and a red run that is expected trains the reader to stop. SECURITY.md already warns about the adjacent failure — a report that falls quiet across a mise upgrade and so reports clean forever — but not about one that stays loud for a known reason until nobody looks.

Evidence

• The Go pin is held behind upstream by the linter pin it must move with #32 is open and deliberate: the Go pin is held behind pending a golangci-lint release that mise's release-age guard hides. Nothing about that state is unknown or unintended.
• While it holds, the weekly scheduled run reports the Go pin as behind and exits 1, every week.
• SECURITY.md § Build and CI supply chain states a red run "means one of three things, and its annotation says which" — a pin is behind and is named, mise could not report, or its output could not be processed. None of the three is behind on purpose.

Suggested approaches

Which is right is genuinely uncertain; these are options rather than a prescription.

• Let the workflow read an accepted-lag declaration — naming a tool, the version accepted, and why — and report a known lag distinctly from an unknown one instead of failing on it. Keeps one workflow, but adds a record that can itself go stale.
• Fail only on pins not already recorded as behind, so the report goes green while a deferral holds and red the moment anything else moves. Loses the standing reminder that the deferral exists.
• Accept the red and rely on the annotation, which already names which pins are behind. This is the current state, worth stating as the null option — the real question is whether the reader keeps reading.