reconciliar_snapshot estampa current_date en fecha_ultima_actualizacion de todo vehiculo en cada import, igual en DEV y en PROD: es el escritor dominante y el que MOVILBA-145 no toco

rutap.reconciliar_snapshot(integer,boolean) lleva 'fecha_ultima_actualizacion = current_date' en la linea 484 de su cuerpo INSTALADO, BYTE-IDENTICO en DEV y en PROD. Dispara sobre TODO vehiculo existente en CADA import, asi que es el escritor DOMINANTE de la columna; el DEFAULT que MOVILBA-145 bajo en DEV solo disparaba en el INSERT de un vehiculo nuevo. Consecuencia que nadie habia visto: DEV NO es el estado bueno al que PROD converge en este campo - las dos bases estampan la fecha de la corrida por el mismo camino, y 145 quedo a medias de los DOS lados. EVIDENCIA DE QUE HOY LA COLUMNA ES RESIDUO DE LOTE, NO DATO DE NEGOCIO (db03, PROD, SELECT only): la distribucion viva entera son OCHO fechas distintas para 2413 vehiculos - 2025-12-08 con 944, 2026-09-18 con 907, 2026-05-14 con 259, 2026-08-14 con 132, 2026-08-05 con 125, 2026-06-29 con 25, 2025-12-16 con 4, 2026-04-30 con 3. 944 y 907 vehiculos compartiendo una fecha al dia es una corrida de import, no 944 vehiculos modificados ese dia. LA PREMISA DE 'SI SACO EL ESTAMPADO QUEDA NULL' ES FALSA, MEDIDA: tomando max(fecha_alta) sobre los periodos de cada vehiculo en rutap.vehiculo_historial_normalizado, los 2413 vivos de PROD resuelven a una fecha derivada del libro y CERO quedarian en NULL; solo 6 de 2413 ya coinciden con ese valor. POR QUE ES UNA DECISION Y NO UN ARREGLO OBVIO: max(fecha_alta) es UNA derivacion defendible, no LA derivacion. fecha_baja de un periodo cerrado, la fecha del expediente en vez de la de vigencia, y 'ultimo evento de negocio' contra 'ultimo periodo presentado' son todas defendibles y dan respuestas distintas para algunos vehiculos. Elegir entre dos valores defendibles es exactamente lo que la regla define como decision, y es el trabajo de MOVILBA-146. Ademas la columna esta en el CONTRATO DE LA API EXTERNA: src/repositories/parque-movil.ts:205 la expone en la descarga de Parque Movil y src/lib/openapi/components.ts:626,646 la declara en el esquema publicado (verificado por coder03 en su carril; la app NUNCA la escribe). PROXIMO PASO QUE NO PIDE APROBACION PORQUE NO ESCRIBE NADA, y es el insumo que 146 necesita: correr la derivacion candidata como COMPARACION de solo lectura que devuelva por vehiculo el valor actual, el candidato y el delta en dias, y reportar (i) cuantas filas cambian, (ii) la distribucion de los deltas, (iii) si el candidato alguna vez mueve la fecha HACIA ADELANTE del valor actual - que significaria que el valor de hoy no es solo viejo sino que esta del lado equivocado -, y (iv) cuantos vehiculos tienen mas de un periodo, que son los unicos donde 'el ultimo' es una eleccion real y no una reformulacion. NO SE TOCA LA FUNCION HASTA QUE 146 DEFINA EL VALOR. Lo que falta es una DEFINICION, no una medicion: cual evento presentado nombra la columna - el ultimo periodo presentado sea del tipo que sea, el ultimo MODIF, o la fecha del expediente en vez de la de vigencia. Ninguna consulta la produce; sale de Elazar o de Eugenia.