feat: generate base SQL schema for GORM modules and check it in doctor

[juancadev-io]

El problema

Un proyecto recién creado con --gorm devolvía 500 en todos los endpoints. El generador escribía el repositorio, la entidad y el controlador, pero nada creaba nunca la tabla que consultan. El servidor arrancaba con buen aspecto y fallaba en la primera petición, sin pista de por qué.

Es el primer camino que recomienda la documentación, así que lo encuentra cualquiera en su primera hora.

Por qué no AutoMigrate

Es la solución habitual y no es la que se usa aquí. Dejar que el proceso altere el esquema al arrancar no es aceptable cuando la base de datos se aprovisiona por adelantado. El CLI ahora emite el DDL como un archivo que una persona revisa y aplica:

db/schema/<tabla>.sql

El motor se resuelve en este orden: DATABASE_ENGINE en .env → database.engine en application.properties (con los placeholders resueltos) → sqlite.

Tipos por dialecto para sqlite, postgres, mysql, mariadb y sqlserver. Este último necesita la forma IF OBJECT_ID porque no tiene CREATE TABLE IF NOT EXISTS. Un motor desconocido genera archivo igualmente, con tipos ANSI y un comentario de aviso de que no están verificados.

TableName() fijado en la entidad

Sin él GORM deriva el nombre del tipo Go — TasksEntity → tasks_entities — que no coincidiría con el DDL. Fijándolo, los dos nombres se renombran juntos o no se renombran.

keel doctor: comprobación 7

Un módulo con GORM y sin archivo de esquema ahora es error. Resuelve la tabla igual que lo haría GORM, leyendo por AST la struct que embebe database.EntityBase, en vez de adivinarla del nombre del directorio. Importa: el mensaje tiene que nombrar la tabla que la aplicación consulta de verdad, y con el directorio se equivocaba (orderitems en lugar de order_item_entities).

Dos arreglos de doctor que salieron en la misma auditoría

• Aprobaba un directorio vacío y salía 0. Que no haya ni keel.toml ni go.mod es ahora error duro: no hay proyecto que evaluar.
• Los archivos opcionales ausentes marcaban aviso pero dejaban el veredicto en verde, así que un proyecto con carencias reales se reportaba sano.

⚠️ Un test cambiado, no añadido. TestDoctor_MissingKeelToml afirmaba el primero de esos dos bugs: usaba un directorio temporal vacío y esperaba éxito. Confundía "falta keel.toml" con "no hay proyecto", así que está partido en dos tests, uno por caso, en vez de retocado. Merece una mirada en la revisión.

Verificación

CRUD completo contra un proyecto generado desde cero: 201 → 200 → 200 → 204. Generación en postgres comprobada aparte, pluralización (order-item → order_items) y resolución por AST con directorio ≠ tabla.

go vet limpio, go build ./... OK, 18 paquetes de tests en verde, 0 fallos.

_{Nota: en local, go test ./... -coverprofile=... -covermode=atomic sale con 1 en tres paquetes que no tienen ningún test, porque al módulo de toolchain de mi máquina le falta la herramienta covdata. Es una carencia de mi instalación, no del código; con el SDK completo de setup-go no debería reproducirse. Si el CI falla ahí, es eso y no otra cosa.}

_{gofmt -l señala internal/keeltoml/keeltoml_test.go, que ya venía así de main y no lo toca este PR — lo dejo fuera para no mezclar.}