/api/log-error attributes appEvents to a session with no genuine-Google gate

/api/log-error POST resolves session attribution WITHOUT a genuine-Google gate. It calls getSession() (may be null, attribution degrades) and separately reads the raw supabase session_id claim, then inserts an appEvents row keyed on that identity. So a session minted outside the app - e.g. via Supabase's email/password provider, open at the API level (factory default, never exercised: 438 auth.users all provider=google) - can create attributed client-error rows without ever having a users row. Existing compensating controls: same-origin gate (1), field char caps (2), email cap (3), DB-backed per-identity flood cap (4, keyed sessionId OR actorUserId OR ip). So this is rate-limited noise/attribution pollution, not an access hole. Found while enumerating Mars's roleless session paths for pmmaster's fleet GoTrue sweep (see MARS-571 for the sibling finding on /solicitar-acceso GET, which WAS a real disclosure and is fixed). Options to weigh, not yet decided: (a) require a genuine-Google identity before attributing, falling back to anonymous ip-keyed rows otherwise; (b) leave attribution as-is and accept it, on the grounds that the flood cap already bounds the damage and dropping attribution would lose real client-error telemetry from legitimate sessions. NOT urgent per pm-mars-cc; do not fold into another push.