fix(db): resolve duplicate migration version 031 (rename profiles-RLS fix to 034)

The security PR (#352) shipped 031_fix_profiles_update_rls.sql while
031_ai_reply_slot_grant.sql (#345) already held version 031. Supabase
keys schema_migrations on the numeric prefix, so applying both to a fresh
DB fails with `duplicate key ... (version)=(031)` (SQLSTATE 23505) — which
is what broke the Supabase Preview check on this PR.

Rename the newer, colliding file to 034 to restore unique versions. It's
idempotent and independent of the AI tables, so re-sequencing after 033 is
safe; a prod DB that already applied 031 will apply this fresh as 034
without side effects.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

supabase/migrations/034_fix_profiles_update_rls.sql

@@ -1,7 +1,14 @@
 -- ============================================================
--- 031_fix_profiles_update_rls.sql — lock down privilege columns
+-- 034_fix_profiles_update_rls.sql — lock down privilege columns
 --                                    on profiles (GHSA-fg5p-2qc3-jmxr, C1)
 --
+-- NOTE: renamed from 031 → 034 to resolve a duplicate migration version.
+-- The 031 slot was already taken by 031_ai_reply_slot_grant.sql (#345),
+-- so shipping this as 031 too made a clean `supabase db` apply fail with
+-- a duplicate schema_migrations key (SQLSTATE 23505). This migration is
+-- idempotent (DROP POLICY IF EXISTS / CREATE OR REPLACE) and independent
+-- of the AI tables, so re-sequencing it after 033 is safe.
+--
 -- The problem
 --
 --   The `profiles_update` RLS policy from migration 017 gates on