Portal: accept 'venus' as a portal appKey scope tag + grant Puia client under venus

Elazar CLI directive 2026-08-01 relayed via coder-venus-cc: venus must use the EVO-83 portal today for venus-scoped CRs + client questions. Gap read from live enamel code: src/lib/app-keys.ts COTENANT_APP_KEYS=[enamel,terra], so the portal form's app selector AND createPortalTicket's atomic authz predicate (vUserGroups group='client' AND appKey=$1) both refuse 'venus'. TWO PARTS. (1) CODE, coder02-enamel-cc: accept 'venus' as a portal appKey. Coder's call whether that widens COTENANT_APP_KEYS or introduces a separate portal-apps const - and the distinction is load-bearing, not cosmetic: venus is NOT a cotenant of eprpywqwzsvrjeaforei, it has its own Supabase project, so here appKey is a SCOPE TAG, not auth tenancy. Conflating the two lists means a future cotenancy check silently reads a scope list. Class-A: touches the authz predicate - audit design-ping before implementing, diff review before push. (2) DB, db-enamel-cc: userGroups row userId=6ebaffae-a195-459e-afe8-b89c3fd73fc0 (sebastian.puia@odontologia.uba.ar), group='client', appKey='venus'. Directed grant, not a data repair. Venus side needs no code change (nav link shipped VENUS-317). Related Elazar ruling, no action here: puia.sebas@gmail.com is his TESTING address - ignore, keep, NOT a merge question; work email is the real identity (relayed to pm-venus-cc for pmmaster's ledger, coder-venus-cc tag msa99u07d3kc).