[kvlonge]

Why

The control UI needs to list checks, their recent results and their SQL. The audit-result mirror holds every field, but nothing read it, and its only typed identity, audit_name, is not unique: one generic audit such as not_null covers many models and columns. In a playground build, 30 checks shared 9 audit names.

Changes

• Checks are keyed by binding_key, now a typed, indexed mirror column filled on ingestion. binding_key covers the audit name, model, column, severity, run scope and thresholds, so a model rename or a severity or threshold change starts a new check history; the old history stays readable under its own key.
• GET /api/control/locations/{location}/targets/{target}/checks returns the newest result of every check. GET …/checks/{binding_key} returns one check's results, newest first (limit, default 50). Both need view on the whole target, like the catalog, and never return SQL, error texts (database errors quote the SQL) or evidence rows.
• GET …/checks/{binding_key}/sql returns the latest result's SQL and error texts. It needs view.sql on the check's model (or the whole target for a check without one) and writes a sql.read audit entry, like node SQL. A denial is audited and returns 403; its reason names the check's node, a known low risk.
• Pre-release control stores are not upgraded: a store created by 0.188.x is refused with an error telling the operator to recreate it.
• Client regenerated; new DuckShop check fixture.

Verification

• New API test on SQLite and PostgreSQL: checks sharing an audit name list separately with their newest outcomes; the listing holds no SQL or error text; history is per key, newest first; viewers get 403 for SQL with a denial audit; developers read SQL and errors with a sql.read audit holding no SQL; other targets are refused. Keying by audit_name fails it.
• cargo test -p sqlbuild-orchestration, client check and test, publication tests, make check-ci.