feat(checks): a check name is a category, not an instance

[passcod]

🤖 Stacked on #479 — review that first; this branch is based on it because both touch the same files.

Why

Backup checks spelled the backup type into the name: backup-staleness:tamanu-postgres, backup-staleness:caddy-config, backup-staleness:tamanu-config, backup-staleness:postgres-config. A deployment backing up four things produced four checks to configure, four catalog rows, and four entries in every listing — for one condition. That defeats the point of a catalog you configure once and then use to get your eyes on things quickly.

The rule

A check name is a category. Anything that varies between instances of the same condition — which backup configuration, which restore intent — goes in the check's detail, where policy rules already read it as check.<field>.

New normative sections: CHK#names (a name is a category, instances go in detail, and how an instanced check aggregates), its application in BKJ, and the AGENTS.md bullet that landed with #479.

How it aggregates

The five backup sweeps — staleness, never, reconcile-missing, report-gap, size-mismatch — now file one check per server with the types as instances:

• each instance is graded through policy on its own, against its own detail, so a rule or silence written for one backup type still affects only that type. That was the whole reason the type was in the name.
• the check settles on its most urgent instance;
• its detail carries every degraded instance with that instance's own result, and its message names them.

So an operator configures staleness once for the fleet, and where a particular type warrants different treatment, writes check.type == '…' rather than acquiring another check.

New in issues.rs: file_check_instances, with file_check reduced to its one-instance case so nothing else changes behaviour. The catalog entry and scoped chain are read once per check rather than once per instance, so a server with a dozen backup types still costs two queries.

Two details worth a look

Silences. A skipped instance leaves the aggregate rather than counting as healthy, and a check whose instances are all skipped is itself skipped. But the observed result still spans every instance including the silenced ones — silencing changes what canopy acts on, never what it saw, which CHK requires. Getting this wrong initially broke scoped_check_policies::server_silence_grades_filings_to_skipped, which is a good test.

Undecidable is not resolved. A stale repo inventory makes the missing verdict undecidable. Where it is stale for every type there is nothing to conclude, so an already-open finding is left alone instead of being cleared on the strength of a lagging inspector. That is easy to lose in a refactor, so there is a test for it.

Migration

Collapses the stored state three ways:

• issues — per-type rows onto one per target. The survivor is the most urgent, then the most recently seen, so it keeps the row an operator is most likely already looking at along with its incident membership and history; losers leave their incidents first, and incidents left with no failing contributor retire.
• silences (scoped policies) — a silence on backup-staleness:tamanu-postgres becomes a rule guard on check.type, so operators keep exactly the suppression they configured instead of it widening to every type or being dropped. Verified to produce the correct if-ladder: {"if": [{"==": [{"var": "check.type"}, "tamanu-postgres"]}, "skipped"]}, with pre-existing rules preserved behind the guard.
• catalog — per-type rows onto one, preferring an operator-reviewed policy over a canopy-seeded one.

All three verified against synthetic data in a rolled-back transaction.

Deliberately not in scope

restore-verification, redaction, and migration-test still carry (type, intent) in their names. A follow-up is in progress.