Retire hub-t.pensanta.com (-t = temp) and make hub.pensanta.com the canonical hub hostname - reverses MSG-93's hub-t target

Elazar ruling 2026-09-18 (CLI): the -t in hub-t.pensanta.com stands for TEMP, so hub-t is the name that retires, and hub.pensanta.com becomes the canonical hub hostname. This REVERSES the direction in MSG-93 (canonical-URL migration names hub-t as the target) and reverses nw-venus-cc's 2026-09-18 recommendation to retire the bare hub name - both were reasoned from the measured state, not from the naming intent, and neither knew -t meant temp. MEASURED STATE 2026-09-17/18, three names on one IP 91.99.136.171: llmmsg-hub.pensanta.com is what is actually wired (whey .llmmsg-env, the MCP shim; /health 401 no-bearer, 200 with). hub-t.pensanta.com resolves, TLS good, /health 401. hub.pensanta.com resolves but serves NO TLS vhost - curl exit 35 tlsv1 alert internal error - because no Caddy site block answers that name (nw-venus-cc confirmed on venus). CONSUMERS: zero bare-hub references under ~/.local/bin on whey AND on venus; whey scan used a bare-hostname regex forced red first on a control holding both spellings - a naive hub-dot-pensanta pattern returns 20+ false hits that are all the substring inside llmmsg-hub.pensanta.com. Lezama NOT scanned by anyone yet. WORK: (1) add the Caddy vhost + cert for hub.pensanta.com on venus so the canonical name answers at all - it currently cannot serve a single request; (2) decide the end state between hub and llmmsg-hub, since llmmsg-hub is the wired one and collapsing to hub means re-pointing every consumer incl. each host's git-ignored .llmmsg-env overlay; (3) cut over consumers; (4) retire hub-t, incl. whatever MSG-93 migrated onto it; (5) scan lezama before declaring coverage. GATE: no host loses hub reach during the cutover - the overlay is the only credential source per host and a wrong URL there silently unhubs that agent.