Extend /api/internal/support-action: access/participant/user/assignment ops (Elazar GO 2026-09-22)

Elazar GO relayed by support-evolutiva-cc, same brief as mars (coder-mars-cc sibling, not yet shipped there either - checked, mars route still ticket-ops only as of 2026-09-22). New ops: access-list, access-approve{id,pickUserId?}, access-reject, access-request-info, practica-participant-remove/add{practicaId,userId,slot} (blocked on SOP-PLUTO-16 db-pluto-cc NULL asistenteId - this is PLUTO-744 remove-asistente gap, now ticketed), user-roles-set, user-create, user-restore, user-lookup{email|legajo|name}, assignment-set{studentId,comisionId}, JTP reassign. idempotencyKey required on every sending/mutating op (mars pattern: supportActionIdempotency table, ON CONFLICT DO NOTHING, store response for replay) - new migration needed, DDL not mine to apply. Design: existing *-actions.ts exports are 'use server' + session-gated (approveAccessRequest, addUserRole, addAlumnoAssignment, createUserFromForm, reactivateInactiveUser) - cannot call directly from a bearer route. Extract *Core(actorUserId, reason) per op mirroring support-reply-core.ts, leave cap check in the thin action wrapper, route passes SUPPORT_SYSTEM_USER_ID. Slices, each its own push: (a) reads - user-lookup, access-list, no idempotency/email/audit gate; (b) non-sending mutations with existing cores - roles, assignment, user-restore, needs migration applied first; (c) sending mutations - access-approve/reject/request-info, user-create, audit-general-cc Class-A gate before push (email path); (d) participant remove/add, new path per PLUTO-744. Reply to support per slice: commit + deploymentId + per-op live-call result against elazarphotos@gmail.com, noting any op not exercisable without prod state.