PLUTO-664 follow-up: REVOKE design for archive/fraud/audit table grants

Design-scope REVOKE DDL (no drafting yet, Class-A, audit-pluto-ca design-ping required before drafting): (1) 5 *Archive tables (practicasArchive/usersArchive/userRolesArchive/comisionesArchive/periodosArchive) — REVOKE UPDATE/DELETE/TRUNCATE FROM postgres, keep INSERT, no legitimate deleter confirmed. (2) comisionJtps/comisionAdjuntos/jtpAyudantes — REVOKE TRUNCATE (DELETE already trigger-blocked by fn_forbidHardDelete, TRUNCATE is the open gap). (3) userAuditLogLegacy — REVOKE UPDATE/DELETE/TRUNCATE (trigger blocks writes unconditionally but grant-level TRUNCATE still open). (4) Candidate for audit to weigh: column-level REVOKE UPDATE (primaryRoleId) ON users FROM postgres. appEvents excluded, blocked on terra's shared log-sink pruner design. Runtime-role probe already confirmed postgres is non-superuser and the actual executing role on both DATABASE_URL paths, so this is live-exposure-relevant not hygiene.