[kvlonge]

Why

The Checks pages in the web UI still ran on mock data. People need to see each check's latest outcome, its history, the SQL that ran and the stored evidence from the live control API.

Changes

• The UI client wires listChecks, getCheck, getCheckSql and getCheckEvidence to the existing person check reads. SQL and evidence reads stay behind view.sql and view.evidence, and the server audits them.
• Thresholds, measured values and text booleans are mapped from the stored result. The check kind and the list's recent outcomes are not reported, so they are nullable and their widgets are hidden.
• Stored results name the sqb run that evaluated them, not a scheduler run, so the pages show that run neutrally instead of linking it.
• Run checks buttons and node links stay hidden until ad hoc runs and the catalog are wired.
• Check pages refresh on node_status, which warehouse history sync emits.
• Short sqb run ids use their random suffix instead of their date.

Known follow-up: linking a result to the scheduler run that produced it needs a server read.

DuckShop: not applicable. This is UI wiring over existing reads; no project shape, data value or lifecycle sequence changes.

Verification

• vitest (mapping tests for thresholds, run ids, history order and evidence), svelte-check 0 errors, production build.
• Live sqb server with sqb location serve syncing a DuckDB project with violation and measurement audits: list, detail, evidence and SQL (audited as evidence.read and sql.read), and a new result appearing on the open page without reload.
• make check-ci and the public-repository scan.