fix: prevent direct client updates to sensitive profile fields (#397)

[diksha78dev]

Summary

This PR prevents authenticated web clients from maliciously modifying sensitive profile stats (xp, level, role, and audit_completed) by adding a row-level trigger that intercepts the updates and restores the original values.

Type of Change

• Bug fix
• New feature
• UI / UX improvement
• Refactor
• Documentation
• Other

Related Issue

Closes #397

What was changed?

• Added supabase/migrations/0023_protect_profile_fields.sql
• Created protect_profile_sensitive_fields() PL/pgSQL function.
• Added a BEFORE UPDATE trigger on the profiles table that checks if the request comes from an authenticated or anon role (web clients).
• If it is a web client, the trigger forces NEW.xp, NEW.level, NEW.role, and NEW.audit_completed to match the OLD values, silently ignoring any malicious payload while allowing other harmless fields like bio to be updated.
• The service_role (used by the backend) bypasses this check and can update stats normally.
• Note on testing: Since the current test suite mocks the Supabase client and does not run against a live database, an automated database integration test harness for this specific trigger was considered out of scope.

Screenshots

N/A

Checklist

• My code follows the project structure and conventions
• I tested this locally (npm run dev)
• No hardcoded secrets or credentials
• I have updated documentation if needed

[vercel]

@diksha78dev is attempting to deploy a commit to the codersogs-3057's projects Team on Vercel.

A member of the Team first needs to authorize it.

[Ayush-Patel-56]

renamed the migration to 0024 since 0023 got taken by another PR that merged today, otherwise this is good, the trigger correctly only blocks anon/authenticated writes so service-role jobs still work fine