22 filas con mas de un historial activo bloquean el sync a prod end to end (gate ~664 de rutap-sync-prod.sql)

Con -v apply=true contra DEV (snapshot 10), tools/rutap-sync-prod.sql aborta en el gate de ~linea 664: 'gate: 22 current-state rows have multiple active historial matches; no id-order tie-break is applied'. El gate es CORRECTO - se niega a elegir por orden de id cual fila viva de historial es la del tramite vigente - pero mientras dispare, el sync a prod NO se puede correr end to end, ni en apply ni llegando al reporte completo. Es PREEXISTENTE y ajeno a MOVILBA-248/254: 254 quito el bloqueo anterior y este quedo al descubierto detras. CONSECUENCIA OPERATIVA: la regla permanente de Elazar es que sincronizar DEV y PROD al libro es rutina sin GO. Hoy esa rutina no termina. Ademas el rewire de ea/eb en :150-151 (MOVILBA-248) y el UPDATE de observaciones de 254 NUNCA corrieron dentro del script - los dos se ensayaron como bloques aislados. O sea que este gate es lo unico que separa a 248/254 de tener evidencia end to end. LO QUE HAY QUE DECIDIR, y es una pregunta de DATO, no de codigo: los 22 vehiculos tienen mas de una fila de vehiculo_historial activa que aparea contra la misma fila abierta del libro. Hay que clasificarlos - artefacto de DEV (import viejo que dejo filas duplicadas) contra ambiguedad real del libro - dominio por dominio, con la definicion del apareo a la vista. Si son artefacto de DEV va una correccion de datos con su respaldo; si es ambiguedad real del libro va al tracker de Eugenia como pregunta por dominio, nunca resuelta por nosotros. NO tocar el gate para que pase: eso es exactamente el modo de falla que ya costo 650 vehiculos con sync-rutap-20260805.sql. Coincidencia a NO confundir: MOVILBA-250 tambien habla de 22 filas, pero son los periodos de largo cero en la ficha. Son dos poblaciones distintas hasta que alguien mida que son la misma.