fix(event): backfill active event social media

app/Domains/Ticketing/Event/documentacion/README.md

@@ -2,36 +2,52 @@
 
 ## Propósito
 
-Administra la configuración temporal de un tenant orientado a eventos y sus fechas disponibles.
+Administra los eventos de un tenant, sus fechas y sus redes sociales.
 
-## Componentes
+## Modelo
 
-- `Models/EventDate.php`: fecha del evento con inicio, fin, tenant y variantes asociadas.
-- `Services/EventService.php`: obtiene y actualiza la configuración de evento del tenant.
-- `Services/EventDateNoticeService.php`: reclama y agrupa los cambios pendientes de cada usuario.
-- `Controllers/AdminApp/EventController.php`: consulta y modificación desde AdminApp.
-- `UpdateEventRequest`: valida datos y reglas cruzadas de fechas.
-- `EventResource`: serializa la configuración de salida.
+`Tenant` tiene muchos `Event`. Cada evento tiene título, subtítulo, descripción,
+ubicación, texto de fechas y `published_at`. Sus fechas se guardan en `event_dates`
+mediante `event_id`. El catálogo `social_media` define las plataformas;
+`event_social_media` guarda la URL y el orden de cada cuenta del evento.
 
-## Endpoints
+La migración `2026_09_18_000500_restore_events` crea un evento por cada tenant que
+tenía datos de evento o fechas, y migra las fechas y redes correspondientes.
+`2026_09_18_000600_associate_active_event_social_media` copia al evento activo las
+redes del tenant que falten, sin sobrescribir las URL propias del evento. El seeder
+de Fiesta Fútbol Infantil hace lo mismo cuando crea el evento en una base nueva.
 
-Bajo `/v1/adminapp/tenant/event`, protegidos por `auth:sanctum` y `adminapp.tenant`:
+## Storefront
 
-- `GET`: obtiene la configuración.
-- `PUT`: actualiza la configuración.
+- `onticket` muestra el evento señalado por `tenants.active_event_id`.
+- `onticket_multi_event` permite varios eventos publicados y mantiene
+  `tenants.active_event_id` en `NULL`. La presentación y gestión de esos eventos
+  en el frontend quedan pendientes de diseño.
 
-Para el storefront autenticado:
+`active_event_id` selecciona el evento del storefront de evento único; no indica
+si está publicado. La asignación de este campo y los cambios de tipo de storefront
+se administran directamente en la base de datos. La aplicación no valida ni
+automatiza esas operaciones.
 
-- `POST /tenants/{tenant}/event-date-notices/claim`: devuelve hasta un aviso de suspensiones y otro de
-  reprogramaciones. Cada cambio se muestra como máximo tres veces por usuario.
+Cuando hay un evento activo, el campo `social_media` del bootstrap usa sus redes,
+igual que `event.social_media`. Las actualizaciones de redes de ese tenant también
+se guardan en el evento. Sin evento activo se conservan las redes propias del tenant.
+
+## API
+
+Los endpoints de AdminApp usan `auth:sanctum` y `adminapp.tenant`:
+
+- `GET/PUT /v1/adminapp/tenant/event`: acceso al evento seleccionado para el
+  storefront de evento único.
+- `POST /v1/adminapp/tenant/event-dates`: crea una fecha para ese evento.
+- `POST /v1/adminapp/tenant/event-dates/{eventDate}/reschedule` y
+  `POST /v1/adminapp/tenant/event-dates/{eventDate}/suspend`: cambios de fecha.
+
+El bootstrap del tenant entrega `event` para el evento seleccionado. No entrega
+una lista de eventos ni existe todavía una pantalla para gestionarlos.
 
 ## Dependencias
 
-Depende de `Tenant`. Las fechas se vinculan con variantes de `Catalog`, que a su vez pueden generar tickets.
-
-## Consideraciones
-
-Los avisos se construyen dinámicamente después de excluir los cambios que el usuario ya vio
-tres veces. Al reclamar los avisos se incrementa una vez cada cambio incluido, aunque varios
-cambios aparezcan agrupados en el mismo mensaje. El reclamo bloquea al usuario durante la
-transacción para impedir que pestañas concurrentes superen el máximo.
+Las fechas se vinculan con variantes de `Catalog`, que a su vez pueden generar
+tickets. Los avisos por suspensión y reprogramación se construyen dinámicamente
+después de excluir los cambios que el usuario ya vio tres veces.