Prevent sharing a diagram with yourself

RLS is the real guard (diagram_collaborators_insert/update now reject
user_id = the diagram's owner, regardless of who's performing the write —
covers a Super Admin acting on someone else's diagram too, not just the
normal owner path); the client-side check in
SupabaseDiagramCollaboratorRepository.add is just there to surface a
friendly message instead of the raw 42501.

Verified: tsc -b and oxlint clean; supabase db reset + 53/53 pgTAP tests
pass (1 new test).

supabase/migrations/20260914000000_prevent_self_collaborator.sql

@@ -0,0 +1,29 @@
+-- Prevents a diagram's owner from ending up as their own collaborator row
+-- (found via manual testing: the UI let you "share" a diagram with
+-- yourself). Ownership already implies full access, so a self-collaborator
+-- row is never meaningful — enforced here, not just in the client, since
+-- the client-side check alone wouldn't stop a Super Admin's "add on behalf
+-- of the owner" path or any other direct API access from creating one.
+
+drop policy "diagram_collaborators_insert" on public.diagram_collaborators;
+
+create policy "diagram_collaborators_insert" on public.diagram_collaborators for insert
+  with check (
+    (public.is_super_admin() or public.diagram_owner_id(diagram_id) = auth.uid())
+    and user_id != public.diagram_owner_id(diagram_id)
+  );
+
+-- The existing update policy had no WITH CHECK at all (only USING) — added
+-- here too, defensively, in case user_id (part of the primary key) is ever
+-- changed via UPDATE rather than delete+insert.
+drop policy "diagram_collaborators_update" on public.diagram_collaborators;
+
+create policy "diagram_collaborators_update" on public.diagram_collaborators for update
+  using (
+    public.is_super_admin()
+    or public.diagram_owner_id(diagram_id) = auth.uid()
+  )
+  with check (
+    (public.is_super_admin() or public.diagram_owner_id(diagram_id) = auth.uid())
+    and user_id != public.diagram_owner_id(diagram_id)
+  );