sys-check.sh's pg skip-list defaults to 'lezama venus' and venus pg is answering - the default is measurably stale

sys-check.sh:415 reads `case " ${SYS_CHECK_PG_SKIP_HOSTS-lezama venus} "`, so with the variable unset the default skip list is 'lezama venus'. Verified on whey's checkout at v2.18.0; the comment at :434 states the same default independently, and :251 records the knob as Elazar's 2026-06-14 decision. WHY IT IS WORTH REVISITING: that default encodes 'venus has no pg transport'. bin-venus-cc reports (2026-09-11 22:03, their measurement, not mine) that venus telemetry pg answered every probe that night. If that holds, the skip entry for venus suppresses a check on a host where the check would now work. Filing rather than changing it: the list is an Elazar decision knob, the counter-evidence is one host-night from another lane, and nobody has re-measured lezama at all. THE TRANSFERABLE POINT, which is why this is a ticket and not a shrug - bin-venus-cc's framing when they placed the OPS-211 spool drain: A REPAIR MUST NOT INHERIT THE SKIP LIST OF A DIFFERENT QUESTION. check_pg returns early for every host in this list, so the drain, had it been folded into check_pg, would have skipped the one host the stranded rows are on. They made it its own function for exactly that reason. Any future repair, backfill or drain hung off a check inherits that check's exclusions silently, and the exclusion was written to answer a different question. TO CLOSE: re-measure pg reachability from whey, venus and lezama; then either narrow the default or record why each entry stays IN THE FILE, next to the default, rather than in a ticket.