feat(sprint-4/etapa-2): migración persistencia proceso/grupos/settings a Supabase

- Scripts SQL 002-004: process_groups, processes, app_settings con RLS
- supabaseProcessRepo: save/getById/getAll/delete con mapeo camelCase↔snake_case
  y limpieza Dexie en delete (actividades/gateways/resources/simulations)
- supabaseGroupRepo: save/getAll/getById/delete; FK ON DELETE SET NULL en processes
- supabaseSettingsRepo: get/update sobre fila singleton
- Stores actualizados: library-store y process-store usan repos Supabase para procesos
  (actividades/gateways/recursos siguen en Dexie hasta Etapa 3-4)
- ImportPage y useReportData actualizados a supabaseProcessRepo
- userId inyectado internamente en repos via supabase.auth.getSession() — no se
  threadea por la call stack; stores mantienen interfaces sin cambios
- 561/561 tests verdes, build limpio

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

supabase/migrations/004_create_app_settings.sql

@@ -0,0 +1,15 @@
+CREATE TABLE IF NOT EXISTS public.app_settings (
+  id           text         PRIMARY KEY DEFAULT 'singleton',
+  group_label  text         NOT NULL DEFAULT 'Cliente',
+  updated_at   timestamptz  NOT NULL DEFAULT now()
+);
+
+ALTER TABLE public.app_settings ENABLE ROW LEVEL SECURITY;
+
+CREATE POLICY "all_app_settings" ON public.app_settings
+  FOR ALL USING (auth.uid() IS NOT NULL)
+  WITH CHECK (auth.uid() IS NOT NULL);
+
+INSERT INTO public.app_settings (id, group_label)
+VALUES ('singleton', 'Cliente')
+ON CONFLICT (id) DO NOTHING;