whey's sys-check drop-in skips pg on whey because 'whey has ZERO telemetry surface' - whey now writes telemetry to venus pg and the premise has expired silently

FOUND 2026-09-11 while answering bin-venus-cc's shim question, immediately after OPS-213 closed the same defect one layer down. OPS-213 narrowed sys-check.sh's DEFAULT to 'lezama' and recorded the list as 3/3 measured. THAT COVERAGE STATEMENT IS ABOUT THE DEFAULT, NOT ABOUT WHAT RUNS ON WHEY - whey overrides it entirely. MEASURED ON WHEY: - /home/rob/.config/systemd/user/sys-check.service.d/skip-pg-whey.conf (mtime 2026-07-14) sets Environment="SYS_CHECK_PG_SKIP_HOSTS=lezama venus whey". So on whey check_pg returns early for ALL THREE hosts, via the unit, regardless of what the shared script now defaults to. - The drop-in states its ground in its own header: 'Telemetry migration 2026-07-12 (Elazar): whey has ZERO telemetry surface/responsibility.' It was a correct and well-documented override when written - it even explains why it is a host-local override rather than a shared-script edit. - THAT PREMISE IS NOW FALSE. whey has a telemetry role and a working transport: ~/.config/telemetry.env (mtime 2026-09-03, i.e. AFTER the drop-in) resolves to PGUSER=telemetry_whey_rw, PGHOST=91.99.136.171 (venus-pub), DB=telemetry, and a live probe tonight returned 'whey pg OK telemetry_whey_rw'. whey's collectors write telemetry to venus pg. SAME FAILURE MODE AS venus's SKIP ENTRY, ONE LAYER UP, AND THE ASYMMETRY IS THE POINT. bin-venus-cc's v2.19.2 distinction: venus's entry died because a TRANSPORT APPEARED UNDER IT SILENTLY, whereas lezama's cannot expire on its own because nothing can be attempted there until someone deliberately provisions a DSN - an act with an author. whey's drop-in is the venus kind: a credential was provisioned on 2026-09-03 and nothing re-read the July premise. An override whose ground is 'this host has no X' needs a re-measurement trigger; one whose ground is a deliberate policy does not. NOT CHANGING IT FROM THIS LANE, and the reason matters: the drop-in cites an Elazar decision by name and date. Superseding it silently would repeat exactly what OPS-213 refused to do to the shared default. It is also NOT obviously wrong to keep - it was written to stop real pg_telemetry CRIT/RECOVERED noise Elazar had complained about, and re-enabling the probe may simply bring that noise back under a premise that is true again. TO CLOSE: (a) confirm with Elazar or nw-whey-cc whether whey now has telemetry responsibility for monitoring purposes, given it demonstrably has a telemetry ROLE; (b) if yes, drop 'whey' from the override and keep the drop-in only if 'lezama venus' still needs overriding at all - note the shared default is now just 'lezama', so the drop-in may be entirely redundant; (c) if no, rewrite the drop-in's header so its ground is the CURRENT reason rather than a premise that measurement contradicts - an override justified by a false statement is the thing the next reader trusts. RELATED: OPS-213 (shared default, closed 3/3). This row is the host-override layer that ticket's coverage statement does not reach.