BREAKER_PM points at a mailbox nobody drains

hub.mjs:4430 hardcodes BREAKER_PM = 'pm-llmmsgsrv-cc'. Elazar shut both pm-llmmsgsrv twins down on 2026-09-20 to save tokens, so every hub path that writes to that name now inserts a row nobody will ever read. Confirmed live: 17 messages sit above pm-llmmsgsrv-cc's cursor (cursors.read_id 121247, max message id 128416), and the newest one is the hub's own reroute of my reply to scrp-memlint-venus. The write always succeeds because stmtInsertMsg does not check registration, so nothing anywhere reports a problem. Paths affected, all writing to BREAKER_PM or the literal name: the scrp-* DM reroute at :8484 (class E coaching_reject 2b), the hub breaker at :6422, the unregistered cc-* sender alert at :7390, the same-cwd/identity-conflict alert set at :4885, and the silence-threshold seed row at :2847 naming pm-llmmsgsrv-cc as whey's escalation target. Second-order defect in the same path: scrp-memlint-venus DMs agents and asks them to 'Reply y when fixed', but the hub correctly refuses any DM to a scrp-* name, so that instruction is unsatisfiable by construction - memlint's lane (bin-venus-cc), not hub code, but it is why this row exists. DECISION NEEDED before any code change - who receives a reroute now that there is no PM. Candidates: the maintainer-registry lookup already armed at boot for dead letters, the sender's own host nw-* agent, or drop the reroute entirely and keep only the coaching reply to the sender, which is the option most in line with MSG-414 (do not manufacture a recipient for a message nobody is owed). Do not just point BREAKER_PM at another single hardcoded name - that moves the black hole.