kpi-burn-alert.sh is blind to every unregistered codex agent - must read v_usage_resolved

kpi-burn-alert.sh reads agent_telemetry.usage_events directly and filters 'agent_name IS NOT NULL AND agent_name NOT IN ("", "(unresolved)")' in both FLOOR_SQL (:708-723) and CODEX_OBS_SQL (:733+). Every codex agent that never registered with the hub therefore stores '(unresolved)' and is EXCLUDED from the burn floor by construction - the 2262 rows / 137.7M tokens on venus over 2026-09-10..11 cannot trip any threshold, and the leg reports 'nobody is over threshold' rather than 'these agents are unmeasurable'. Measured by bin-venus-cc 2026-09-13; carve-out from the fleet stop granted by pmmaster-evolutiva-cc (tag pmmaster-evolutiva-cc-mtzaexj2ua2l), priority 1, because a burn alarm blind to the codex mass is the exact gap in Elazar's find-who-spends-tokens order. FIX: read agent_telemetry.v_usage_resolved instead of usage_events, and select its resolved agent_name column, not agent_name_observed. ACCEPTANCE IS A FORCED RED, not a green run: exercise it against a known unregistered codex agent (e.g. coder02-terra-ca, 799 rows / 50.9M on /home/rob/Documents/work/pensanta/websites/evolutiva-pensanta-com/terra/agents/coder02-terra) and confirm it is now VISIBLE to the leg where it previously could not appear at all. THREE CONSTRAINTS THAT ARE NOT STYLE POINTS. (1) v_usage_resolved is gaining a 4-value attribution_source column under OPS-268 (ingest/registered/path_derived/unresolved). A path_derived name is DERIVED FROM A WORKING DIRECTORY, NOT CLAIMED BY AN AGENT - do not send an advisory DM addressed to a derived name without deciding that explicitly; an alarm that DMs a name nobody registered is a new defect, not a fix. (2) THE VIEW HAS A SILENT FALLBACK: its mirror_fresh CTE requires a collector_runs row with source_kind='roster_sqlite_mirror' AND status='ok' within 7 days, and when that is false the CASE falls through to the raw agent_name for EVERY row - resolution vanishes fleet-wide with no error and the burn leg silently returns to today's blindness. Currently ok at 2026-09-13 04:00:10Z. Force that state too, or the regression is undetectable. (3) Do not apply this before OPS-268's tracked-schema reconcile lands: the TRACKED schema.sql has no withdrawn_at and none of the claim-window predicates, so a reapply would regress the view to a naive join that credits withdrawn claims.