106003 El servicio no arranca porque el rol de base de datos con el que ejecuta tiene de más

Qué ha pasado

DB-004 del ADR-0015. Al arrancar en prod se le pregunta AL MOTOR con qué rol ejecuta de verdad —no se confía en el DSN, que dice a quién pides ser y no quién eres—, y se exige que ese rol no sea superusuario (ni el de login ni el EFECTIVO tras un SET ROLE), no tenga BYPASSRLS, no posea las tablas y no pueda hacer DDL. Cualquiera de esas cuatro cosas le permite leer los datos de cualquier cliente, que es justo lo que la arquitectura de aislamiento existe para impedir, así que el proceso NO levanta. El mensaje dice cuál de las cuatro falló y con qué rol, para que se pueda discutir con el dato delante. El MISMO número cubre el tercer desenlace, que es distinto y no tumba nada: si no se pudo PREGUNTAR —base caída, permisos, tiempo agotado— el servicio SÍ arranca y es /health/ready quien responde 503 con el motivo. Ni verde ni rojo: un hueco de medición no se interpreta, y tumbar el arranque por no poder preguntar convertiría una base lenta en una caída total.

Cómo se soluciona

Si NO CONFORME: revisar con qué rol se conecta la app (REPORTS_DB_DSN_APP) y quitarle lo que sobra; el rol propietario del esquema es para las migraciones y vive solo en el servicio migrate. OJO a la trampa medida el 09-sep: quitarle el superusuario al rol PROPIETARIO deja la API sin autenticar al 100%, porque auth_lookup depende de que lo sea. No es ese el rol que hay que tocar. Si NO MEDIBLE: es la base o la red, no los permisos. /health/ready dice el motivo concreto.

Qué hacer mientras tanto

NO CONFORME no tiene paliativo a propósito: el servicio no está sirviendo. NO MEDIBLE sí sirve tráfico, pero se declara degradado para que ningún balanceador ni health-gate lo dé por sano mientras esa comprobación siga sin poder hacerse.

Dónde se lanza

db_conformidad.py — comprobar_rol(); app.py — create_app() en env=prod

El número viaja en la respuesta o en el registro: sí.