Fresh self-host fails at migration 0008: direct storage-table deletes rejected (SQLSTATE 42501) on current Supabase

Describe the bug

A fresh self-host fails during supabase start (or bun run setup:env) while applying migrations:

Applying migration 0008_preview-img-storage.sql...
Stopping containers...
ERROR: Direct deletion from storage tables is not allowed. Use the Storage API instead. (SQLSTATE 42501)
At statement: 0
delete from storage.objects where bucket_id = 'preview_images'

0008_preview-img-storage.sql and 0012_file-transfer-bucket.sql both start with direct deletes against storage.objects / storage.buckets. Recent Supabase versions reject direct writes to storage tables, so every fresh clone on a current CLI dies at migration 0008 and the backend never comes up.

Steps to reproduce

1. Fresh clone on a machine with a current Supabase CLI (hit with 2.75.0; repo pins ^2.45.5, where it still passes)
2. cd apps/backend && supabase start
3. Migration 0008 fails with SQLSTATE 42501, containers stop

Expected behavior

Fresh self-host completes supabase start and applies all migrations.

Suggested fix

On a fresh database the deletes are no-ops, so the delete+insert pair can become an upsert with identical results:

insert into storage.buckets (id, name, public)
values ('preview_images', 'preview_images', true)
on conflict (id) do update set public = excluded.public;

Same for file_transfer in 0012. Verified locally — supabase start completes and both buckets exist with the right visibility. One behavior note for review: the old code also wiped existing objects in those buckets on re-run; the upsert preserves them.

Happy to open a PR — have the change ready.