Hub: widen CONTACT_ALIAS to an exact-match alias set for the human (8 senders/7d fail to reach him)

PM spec'd 2026-08-10, queued behind MSG-280's audit; PM gates, I author. Cause: 8 [dm-diag] recipient_not_registered lines / 8 distinct senders in 7d, all DMing the human under non-canonical names (elazar x6, elazarpimentel, elazarpimentel@gmail.com) - every line already carries human_exists=1. One affordance defect with 8 witnesses. Spec: replace single CONTACT_ALIAS ('elazar-contact', hub.mjs:3375) with an exact-match SET resolving to HUMAN_AGENT; keep elazar-contact for existing callers; deliver rather than reject; return the resolved identity in the response ON EVERY aliased send (that field is what teaches); keep [dm-diag] firing for names that resolve to nothing and silent for ones that now resolve. MY DECISIONS (accepted by PM's ask): (1) add elazar/elazarpimentel/elazar-contact to RESERVED_AGENT_NAMES - they are grammatically valid agent names so a collision is creatable; verified no roster row and no message ever sent under any today. (2) do NOT add elazarpimentel@gmail.com to RESERVED_AGENT_NAMES - isValidAgentName's regex ^[a-z0-9][a-z0-9_-]{1,63}$ already rejects @ and . so the set is unreachable for it; adding it would be a guard-shaped no-op. Comment the grammar instead. (3) include the email as an alias LITERAL, never a pattern - matching on @ means owning address parsing forever.