EVO-52: extend support-api for full SOP-ticket CRUD (status transitions incl. close/resolve, private Elazar+stakeholder-only comment type, notify-list on ticket events) — bearer-invokable, no direct DB/chrome-mcp/manual-human path

EVO-52 umbrella (Elazar directive via pmmaster-evolutiva-cc, relayed to Mars as sub-item, 2026-07-15). Trigger: SOP-VENUS-15 sat open/un-notified because coder-venus-cc had no API path to close/notify a solved ticket. Extend Mars's support-ticket surface (currently family-B session-gated server actions only: replySupportTicket/closeAndNotifySupportTicket/updateSupportTicket in administrar/soporte/actions.ts, no bearer API — per evolutiva-support-api.md) so PM/coder agents can fully CRUD SOP tickets programmatically: (1) status transitions incl. close/resolve via a bearer-gated endpoint (pluto's support-reply bearer pattern is the closest precedent, but pluto itself lacks close-via-API too — PLUTO-501); (2) a private comment type visible ONLY to Elazar + the ticket's stakeholder agent, NEVER the end-user reporter — this is a genuine authz/visibility surface, not a UI nicety; (3) a notify-list (agent name + email) that fires on ticket events. Hard rule from Elazar: agents never write directly to the ticket DB, never drive a ticket via chrome-mcp, never ask a human to do it manually — everything through this API. Class-A: new bearer-invokable close/status-transition path + private-comment visibility gate (authz-shape) + likely schema additions (comment type, notify-list) = DDL. Routes to full team, audit-mars-ca pre-implementation design review before build. Cross-project: PLUTO-563, VENUS-252 (venus is P0, live blocking case) are the sibling items — check for a converged shared shape before Mars build starts, don't design in isolation.