fix: remove reports created_by FK constraint for prototype

Issue: Foreign key constraint violation when creating reports
- reports.created_by referenced practitioners.id
- Code was storing auth.uid() instead of practitioner.id
- Demo practitioners have user_id: null (no auth link)

Solution (prototype):
- Drop FK constraints on created_by and updated_by
- Store auth user ID directly without constraint
- Added migration: 20251123_fix_reports_created_by_constraint.sql

Note: In production, populate practitioners.user_id and restore
FK constraints for proper data integrity.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

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

docs/release/ops-log.md

@@ -33,3 +33,13 @@
 - Component ownership verduidelijkt: EPDHeader = algemene navigatie (logo, search), ClientHeader = patient context (naam, status, acties)
 - Resultaat: EPDHeader vereenvoudigd van 91 naar 34 regels (-57 regels), duidelijke separation of concerns
 
+## 2025-11-23 — Reports created_by foreign key fix (Colin)
+- **Bug fix**: Foreign key constraint violation bij opslaan rapportages
+- Probleem: `reports.created_by` had FK constraint naar `practitioners.id`, maar code sloeg `auth.uid()` op
+- Root cause: Practitioners tabel heeft `user_id` kolom, maar alle demo records hebben `user_id: null` (geen link naar auth users)
+- Error: `insert or update on table "reports" violates foreign key constraint "reports_created_by_fkey"`
+- Oplossing (prototype): Foreign key constraints verwijderd voor `created_by` en `updated_by` kolommen
+- Migratie: `20251123_fix_reports_created_by_constraint.sql` toegepast via Supabase MCP
+- Resultaat: Rapportages kunnen nu opgeslagen worden met auth user ID zonder FK constraint
+- **Note voor productie**: In productie zou je practitioners.user_id vullen en FK constraints herstellen voor data integriteit
+

supabase/migrations/20251123_fix_reports_created_by_constraint.sql

@@ -0,0 +1,19 @@
+-- Migration: Fix reports created_by constraint for prototype
+-- Remove foreign key constraint to practitioners table
+-- For prototype: store auth user ID directly without FK constraint
+
+-- Drop the foreign key constraints
+ALTER TABLE reports
+  DROP CONSTRAINT IF EXISTS reports_created_by_fkey;
+
+ALTER TABLE reports
+  DROP CONSTRAINT IF EXISTS reports_updated_by_fkey;
+
+-- Add comments for clarity
+COMMENT ON COLUMN reports.created_by IS 'Auth user ID (from auth.users) - no FK constraint in prototype';
+COMMENT ON COLUMN reports.updated_by IS 'Auth user ID (from auth.users) - no FK constraint in prototype';
+
+-- Note: In production, you would:
+-- 1. Ensure all practitioners have user_id populated
+-- 2. Look up practitioner.id from practitioners WHERE user_id = auth.uid()
+-- 3. Restore FK constraints for data integrity