feat: Supabase edge function example

[Chriztiaan]

This PoC takes the original write improvements PoC a step further and wedges the endpoint handling, mapper, and persistence logic into a Supabase edge function.

We get two benefits from this approach compared to the original SupabaseConnector plus Supabase backend:

• We move all translation/mapping logic from the client to the backend.
• We get proper transaction support without migrating off Supabase or managing a separate backend (enabling rollback on failure is something the Supabase JS SDK can't do today)

AI disclosure

This PR was created with the help of Claude Code. Help constitutes assistance in research, planning, and rough outline of implementation. Beyond having a hand in the implementation, I have also manually tested this work.

[rkistner]

As I understand, specific advantages over the default "demo" Supabase connector that uses the Postgrest APIs directly:

1. This fits in with the standard write API we're creating.
2. This handles atomic transactions.
3. This improves performance for large transactions, potentially eliminating the need for the current batching strategies (which all have trade-offs).

One additional aspect to investigate, if not done already: How does/can this handle JSON and custom types? Right now, users typically need to do workarounds like parse JSON strings into JSON before uploading, in their uploadData function. Can the implementation here handle that automatically for JSON/JSONB columns? What about others, such as bytea (typically synced as base64) or custom types?

If those cannot be handled automatically, is there perhaps a good pattern to handle these on the db side? For example, let the developer create a view or RPC function that does the mapping, instead of customizing the code.

Another thing that will be important here is RLS: Supabase users are used to relying on RLS for everything. The persistance logic here should ideally use the same setup that Postgres does, to let Postgres apply the same RLS rules. I didn't confirm, but I assume the current approach effectively writes as a "super-user" and bypasses RLS.