Stuck-agent alert silently discards an unresolvable-host case

The stuck-agent alert discards an unresolvable-host alert silently. Make the failure LOUD, do not widen the inference. hub.mjs:10611 is a bare `continue` when inferHostFromAgent (:10345) returns anything outside /^(venus|whey|lezama)$/. The alert is discarded and nobody is told, so a hub that cannot place an agent looks exactly like a hub with nothing to report. Third instance of that class today (the other two: a matcher whose "no WI number" bucket was indistinguishable from "no gate"; audit-llmmsgsrv-cc registered with last_poll_at NULL reading as ALIVE to a sender). SPEC, agreed with pm-llmmsgsrv-cc: make the unresolvable case surface - a log line at minimum, and a decision on whether it also warrants a DM and to whom. Do NOT widen the name regex and do NOT extend the KNOWN map at :10365 as the fix: guessing a host routes a REAL alert to the wrong nw agent, which is strictly worse than dropping it. The KNOWN drift (it carries audit-llmmsgsrv-ca but has no audit-llmmsgsrv-cc entry, and audit-llmmsgsrv-cc is live and polling as of 2026-09-11) is EVIDENCE for this item, not a fix to apply - patching one name leaves the class broken. EXPOSURE IS LATENT, NOT LIVE, which is why it ranks below MSG-380/381/383. Measured 2026-09-11 by replicating inferHostFromAgent verbatim over the live roster: 66 rows, 22 resolve to 'unknown', but the detector requires a polling shim so scrp-* one-shot senders, llmmsg-srv-hub and wi-cli can never reach it. Restricted to last_poll_at NOT NULL: 42 rows, 41 routable, 1 dropped - elazar-the-user-human-llmmsg-srv, where dropping is CORRECT per the no-status-pings rule and the :10607 comment. So nothing is being lost today. The defect is that the day something IS lost, it will look identical to healthy. Split out of MSG-379 (closed as refuted) at pm-llmmsgsrv-cc's instruction; do not fold it back in.