Security: revoke default anon/authenticated SELECT grants across Mars public schema (83 relations incl appEvents family)

audit-mars-ca mig026 review found ALL 83 relations in Mars public schema (incl appEvents + its view family vAppEvents25/50/100/vAppEventsTriage48h/vAppEventsLast24h) carry Supabase default anon+authenticated SELECT grant, confirmed via information_schema.role_table_grants. anon API key is client-embedded, so any user can query PostgREST directly bypassing app authz entirely -- appEvents exposes actorUserId + error messages + routes. App itself never uses client-side PostgREST against these tables (grep confirmed all reads go through server-side pg Pool in src/lib/db.ts) so grants serve no legitimate current purpose, likely unrevoked Supabase project defaults. Distinct from the standing NO-RLS-by-design policy (this is a coarser schema-wide grant, not row-level policy). Fix = REVOKE ALL ... FROM PUBLIC/anon/authenticated across the relations that don't need it, after auditing which (if any) legitimately need it. db-mars-cc already applied a narrow spot-fix (security_invoker + REVOKE + GRANT applog_reader) to the new vFriction7d view at audit's request; that is not the schema-wide remediation. Class-A (schema DDL + authz-adjacent security surface) -- needs pre-impl audit design-review + Elazar go before the blanket REVOKE; the read-only discovery audit (which relations need anon/authenticated access) is safe/reversible and can proceed now.