vehiculo_historial.estado_id sin poblar en prod y dev, poblado en staging

Medido por db-mba-l-cc 2026-08-07 en los tres entornos. HECHO: vehiculo_historial.estado_id esta NULL en el 100% de las filas vigentes de PROD (0 de 1588) y de DEV (0 de 1588), pero POBLADO en el 100% de STAGING (1600 de 1600, todas 116/ALTA). No es columna muerta: es divergencia entre entornos. ORIGEN: el importador, no la app. En staging las filas las escribieron staging-excel-load-2026-06-22 (1517), import-2026-06-29 (37), import-2026-08-05 (34) y staging-excel-entidad-fix-2026-06-22 (12), todas con estado. En prod y dev los mismos cargadores POR NOMBRE (staging-excel-load-2026-06-22 1539, import-2026-06-29 37, staging-excel-entidad-fix-2026-06-22 12) escribieron cero. Corrio una version distinta del script por entorno y la de prod/dev omitio el campo. LA APP SI LA ESCRIBE: src/repositories/vehiculos.ts resuelve estadoId en el alta con fallback a ALTA cuando no viene (lineas 452-465) y lo inserta en el historial (538, 565); src/actions/vehiculos.ts lo arrastra en la edicion y lo registra en cambios (269, 298). Toda fila creada por la aplicacion lleva estado. PENDIENTE DE CONFIRMAR al trabajar el WI: la unica fila de dev escrita por un usuario real (creado_por 20394678369) tambien esta en NULL - se creo antes de esa logica o por otro camino. IMPACTO: v_vehiculo_historial expone estado, asi que la UI de historial muestra el campo vacio en prod/dev y lleno en staging. NINGUN consumidor de la API lee esta columna - la API lee vdc.estado_id, que si esta poblada en los tres entornos. No urgente, no bloquea a nadie. VEREDICTO: muerta por OMISION del importador, no por diseño. Esto es un BACKFILL, no un drop. ALCANCE SUGERIDO: fijar estado_id = 116 (ALTA) en las filas vigentes de prod y dev creadas por los tres cargadores de importacion, dejando INTACTAS las filas de usuario; verificar despues que los tres entornos coinciden. GATE: requiere GO EXPLICITO DE ELAZAR POR ENTORNO - es un UPDATE sobre datos de produccion. Relacionado: MOVILBA-1 (copia staging->dev). Si esa copia se hace primero con active-only desde staging, dev queda poblado por arrastre y el backfill se reduce a prod.