codex attribution must resolve at READ time on venus - a stored repair is self-erasing

MEASURED 2026-09-13 (bin-venus-cc, pmmaster carve-out). Attribution is baked at INGEST on the ORIGINATING host. collect.py:733-747: on lezama/whey args.host != ROSTER_HOST and no --roster-db, so roster={}, claimed_agent() returns None, and '(unresolved)' is written into usage_events.agent_name by THAT host's own apply(). Venus's collect run reads only venus's ~/.codex/sessions. THERE IS NO VENUS-SIDE INGEST OF LEZAMA'S CODEX ROWS TO HOOK, so "resolve venus-side at ingest" has no location. agent_telemetry.roster_claims (the all-hosts mirror, collect.py:468-500, v0.4.4/KPI-68) is WRITE-ONLY: nothing ever reads it back to repair a row. A STORED REPAIR IS A TREADMILL. agent_telemetry.ingest_usage_events() upserts ON CONFLICT (event_key) DO UPDATE SET agent_name=EXCLUDED.agent_name, and lezama re-upserts the same event_keys every run (collector_runs shows 5000 and 795 rows re-upserted at 03:39Z). Any UPDATE that repairs agent_name is rewritten back to '(unresolved)' on the next collect. READ-TIME RESOLUTION (a view/join) is the only shape durable without changing lezama. JOIN KEY MUST BE (host, project_path, provider) - project_path alone fans out: '/home/rob/.local/bin' matches bin-venus-ca, bin-lezama-ca AND bin-whey-ca. Claude claims are stored DASHIFIED ('-home-rob--local-bin') and codex claims RAW ('/home/rob/.local/bin'); the codex join is on the raw form. COVERAGE, 3-day window, claim-window-honest (observed_at >= claimed_at AND < coalesce(withdrawn_at,'infinity')): lezama 3855/4009 unresolved rows resolve (96.2%), 154 NO-MATCH - coder04-mba-l-ca 1696, coder-mba-l-ca 1238, db03-mba-l-ca 645, nw-lezama-ca 203, bin-lezama-ca 73. WITHOUT the window test all 4009 "resolve", which credits two WITHDRAWN claims (nw-lezama-ca and bin-lezama-ca, withdrawn 2026-09-11 14:45Z) 276 rows / 18.3M tokens. collect.py:740 refuses a stale name on exactly this reasoning; the window test is not optional. SECOND, SEPARATE DEFECT - DO NOT MERGE: venus 2262 rows / 137.7M tokens and whey 297 rows in the same window are NO-MATCH because NO CODEX CLAIM EXISTS for those paths at that time, not because a join is missing. roster_claims holds only 3 venus codex claims, all claimed 2026-09-13 03:00-03:16Z. The join fixes none of that mass; it needs a registration fix. Venus's 2026-09-13 rows are 118/118 already resolved, so venus ingest works - the venus gap is historical. NOT A PIPELINE STALENESS FAULT: observed_at is the codex event's OWN timestamp (collect.py:381), not ingest time. lezama codex max(observed_at) 2026-09-12 08:15Z and whey 2026-09-11 02:44Z are real quiet, not a broken collector - collector_runs shows lezama and whey both ok at 03:39-03:45Z. STATUS: measured, nothing built or changed.