Flujo de generación de imagen por cinco créditos

Verificado con el commit 2a1a04a.

La generación de imagen es el ejemplo mínimo de un flujo de pago con forma de producción. El proveedor local genera SVG y no llama a un modelo comercial; el valor es la cadena que lo rodea. Cada solicitud aceptada cuesta exactamente cinco créditos comunes de la organización.

ENABLE_DEMO_FEATURES=true
ENABLE_IMAGE_GENERATION_MOCK=true
IMAGE_GENERATION_MOCK_FAILURES=0

Ejecuta pnpm dev:all, inicia sesión con la cuenta demo y abre /es/tasks/image-generation. La UI conserva una clave idempotente y consulta el estado tenant-scoped.

1. La API comprueba origen, límite, auth, tasks.image_generation y cuota mensual.
2. (user_uuid, type, idempotency_key) identifica la tarea; una huella rechaza otra petición con la misma clave.
3. task_image:<task uuid> identifica el gasto de cinco créditos; replays concurrentes devuelven el débito existente.
4. task_image_generation:<task uuid> deduplica el job durable y repara caídas entre tarea, gasto y despacho.
5. El worker llama al proveedor con UUID estable, escribe y verifica un objeto privado Garage/S3 y activa su archivo.
6. La consulta firma una URL corta después de resolver el archivo dentro de la organización.

pending_payment → queued → running → succeeded
                           ↘ refunding → failed

El proveedor dispone de cinco intentos y el job de ocho, reservando tres para compensación. El fallo terminal entra en refunding, añade un reembolso determinista y solo entonces marca failed. El replay no duplica proveedor ni reembolso.

Usa IMAGE_GENERATION_MOCK_FAILURES=5 para probar el fallo. Tests de base prueban un gasto y un reembolso; Playwright prueba replay, cambio exacto de cinco créditos, worker, Garage y descarga firmada.

Sustituye solo src/services/ai/image.ts por el proveedor real y conserva idempotencia, AbortSignal y contratos de tarea, crédito, job, storage y error.

Relacionado: Libro de créditos, Storage privado, Jobs durables y Pruebas y CI.