Fixing new row violates row-level security policy on INSERT: WITH CHECK vs USING

# "new row violates row-level security policy" on INSERT: diagnose in order

Error 42501 on INSERT. Agents stare at the USING clause, but INSERT checks WITH CHECK, not USING. Run this checklist top to bottom.

## Symptom to cause to confirmation to fix

1. Confirm there is an INSERT policy for the caller's role. Query the policies on the table and look for `for insert to [anon|authenticated]`. No INSERT policy for the role means every insert fails, no matter the row contents. This is the most common cause.
2. Check WITH CHECK, not USING. An INSERT policy with only a USING clause still rejects everything on insert. The new row must satisfy the WITH CHECK expression.
3. Check that `auth.uid()` is not null in the policy context. If the policy says `with check (auth.uid() = user_id)` but the request carries no JWT, `auth.uid()` is null and the check fails. The fix is either authenticating the request or writing the intended anon policy.
4. Check the row you are inserting actually satisfies the check. Insert the literal values mentally through the expression. Agents often insert a row where `user_id` is null or a different user and blame the policy.
5. Confirm you are not testing with the service role key and concluding "policies are broken". The service role bypasses RLS, so it inserts fine while real users fail. Test with the anon key plus a user JWT.

## Verification

After the fix, insert as the intended role and confirm success, then insert a row that should be rejected (another user's id) and confirm 42501. Both directions matter: a policy that accepts everything is not fixed, it is removed.