[kvlonge]

Why

The UI's check panel shows the rows a failing check captured. Those rows are warehouse data, so reading them needs its own permission and an audit entry, separate from listing checks and from reading their SQL.

Changes

• GET /api/control/locations/{location}/targets/{target}/checks/{binding_key}/results/{event_id}/evidence returns {columns, rows, truncated} for one recorded result, or null when that result does not belong to the check, target or location.
• Columns are the sorted union of the captured rows' keys. Each row is aligned to them, with null for a missing key. Cells keep their JSON type, including booleans.
• Needs view.evidence on the check's attached node, or on every node when that node is not in the current snapshot. No built-in default role grants it.
• Every read, found or not, writes an evidence.read audit entry holding the scope, binding_key, event_id and found, never the rows. If the audit write fails, nothing is returned.
• Evidence stored in an unexpected shape returns the generic 500 without echoing the stored value.
• The SQL and evidence reads share one authorize, read and audit helper.
• TypeScript client regenerated.

Verification

• cargo test -p sqlbuild-orchestration --all-features: endpoint tests on SQLite and PostgreSQL cover the administrator read, developer denial with the narrowed scope, the audit entry, a result from another check returning null, a failed audit write disclosing nothing, and malformed stored evidence.
• make check-ci, public-repository scan.
• Review: one read-only pass. Its finding (malformed evidence echoed as a 400 before the audit) is fixed.
• DuckShop: the edge case is the existing check_identity.json fixture, extended with captured rows.