Changelog

1.2.0 — 2026-03-17

Nuevo endpoint POST .../orders/{orderToken}/confirm-payment: el canal notifica que ha procesado el pago con su pasarela propia.
Ejecuta el mismo proceso de cierre que el webhook de Redsys: orden completada, asientos vendidos, tickets enviados.
Validación de importe declarado vs. total de la orden.
Idempotente: llamadas repetidas sobre una orden ya completada devuelven 200 sin reejecutar el proceso.
Refactorización interna: lógica de cierre de orden extraída a OrderCompletionService (compartida con RedsysPaymentController).

Nuevo flujo de autenticación: POST /auth/token intercambia widget_key por Bearer token Sanctum.
El token anterior se revoca automáticamente al solicitar uno nuevo.
Nuevo endpoint público GET /{slug}/config para configuración de branding del canal.
POST .../orders: order_token ahora es opcional en el flujo B2B — el backend lo genera automáticamente.
Nuevos endpoints de gestión de items: bulk add, bulk delete, sector (zonas no numeradas), change-rate.
Payload de eventos simplificado: sin fees ni manual_promotions.
Payload de sesión saneado: sin venue, fees, timestamps internos.

Columna widget_key añadida a sales_channels (64 chars, nullable, unique).
SalesChannel implementa HasApiTokens (Sanctum) para emitir Bearer tokens.
Middleware ValidateSalesChannelToken: valida Bearer token y adjunta canal autenticado al request.
Middleware InjectOrderTokenForB2B: inyecta order_token UUID si el cliente no lo envía.
Rutas de gestión de widget_key en admin y promotor: POST/DELETE /{channel}/widget-key.
Eliminado controlador legacy SalesChannels\PublicSalesChannelController (no estaba en uso).