kpi-burn-alert all legs fail: telemetry_ro has no SELECT on v_usage_resolved

kpi-burn-alert.sh v1.25 switched to agent_telemetry.v_usage_resolved under VENUS-411 and every query leg now fails. Journal, venus system scope, unit kpi-burn-alert, 2026-09-13 04:15:00: 'LEG-FAILED burn_codex: ERROR: permission denied for view v_usage_resolved', same for burn_level and derived_lookup. CAUSE: the script connects as telemetry_ro and telemetry_ro holds no SELECT on the view. This is NOT drop-and-recreate grant loss - measured before any of tonight's applies, telemetry_ro already had no SELECT on v_usage_resolved, usage_events or roster_claims, so the recreate restored the grants faithfully and the role simply never had it. The DEGRADED DM's own guess, 'another lane's DDL moved under this query', is wrong; nothing moved. FIX, nw-venus-cc's as view owner: GRANT SELECT ON agent_telemetry.v_usage_resolved TO telemetry_ro, and audit the other three views in the schema for the same gap if telemetry_ro is intended as the schema's read role. The unit is currently 'failed' with the timer active and waiting, so it retries every 15 minutes and re-emits DEGRADED until the grant lands. WHAT THIS COST AND WHY IT MATTERS FOR VENUS-411's ACCEPTANCE: the switch-over's stated acceptance was a forced red against a previously-invisible codex agent. That acceptance was never run, and had it been run it would have caught this in the first invocation - a permission error is exactly what a forced-red exercise surfaces and a green-path check does not. Do not close VENUS-411 on the grant alone; the forced red, the derived-tier DM decision and the mirror_fresh false-state check are all still owed. WORTH PRESERVING, NOT FIXING: the script degraded honestly - it named the three failed legs, stated 'no all-clear is implied for the failed one(s)', and refused to render its own silence as a clean run. That behaviour is why the cause took two minutes to find. Any fix must leave it intact.