support-action accepts only ticketId (uuid): nothing resolves a ticketNumber or SOP-PLUTO-N ref to an id

Measured 2026-09-28 working SOP-PLUTO-16. Every POST op on /api/internal/support-action takes ticketId as a UUID and only that - ticketNumber returns 400 'missing or invalid ticketId (uuid)'. Nothing in the API resolves a number or a public ref to an id: GET ?ticketId needs the id already, and GET with no query returns only the OPEN list, so any CLOSED ticket, or any ticket cited by the SOP-PLUTO-N code a user or another agent quotes, is unreachable without a direct DB connection. mars accepts ticketId, ticketRef or ticketNumber on the same ops, so this is a divergence, not a design choice. ASKED FOR: accept ticketRef and ticketNumber wherever ticketId is accepted, on POST ops and on the GET read path. vSupportTicket already computes ticketRef as 'SOP-PLUTO-'||ticketNumber, so this is a lookup, not new state. IMPACT: any agent without a pluto DSN cannot act on a ticket by the only identifier the outside world uses. I hit it today and had to resolve the id by SELECT; before 2026-09-28 I held no pluto DSN at all, which would have made the close impossible through the API. Not urgent - support-evolutiva-cc now holds a named read-only role (support_evolutiva_cc_ro) and can resolve ids itself. Filed because the gap is real and silent, not because it currently blocks me. CORRECTION to an earlier claim of mine on PLUTO-744, so it is not carried forward: I first wrote that support-action has 'no list and no get op'. The POST op switch has neither, which is what the 400 enumerates, but reading is GET-only and works. The genuine gap is the id resolution described above. Raised to coder-pluto-cc by DM (tag support-evolutiva-cc-mul3b2g06iq4) asking that lane to file and own it; filing here so it exists either way.