El diff del historial compara modelo de carroceria contra una columna que el import nunca llena

Item 24 de Eugenia: 'Tomo un cambio no realizado en el modelo de carroceria ya que figura previamente en el historial.' Es un defecto real, pero la causa no es la que sugiere el reporte. MEDIDO por db02 en DEV 2026-09-17, dominio AG202SZ. El periodo anterior (fila de import id 234797, cierra 2026-09-15) YA trae carroceria_fabricante = 'TODO BUS'. Lo que tiene NULL es carroceria_modelo. Y NINGUNA fila de import de ese dominio llena carroceria_modelo - tampoco las de AA013AD, chequeado aparte. El pipeline de import escribe unicamente carroceria_fabricante. Entonces el diff de la app compara carroceria_modelo, que del lado import esta SIEMPRE vacia, contra el valor que la app escribe en la primera edicion. Resultado: 'Modelo de carroceria: De (vacio) A: TODO BUS' aparece en la PRIMERA edicion de CUALQUIER vehiculo de origen import, haya cambiado o no la carroceria. No es una fila mal escrita: es estructural. Por eso el item 5 de Eugenia (mismo sintoma con ADAS/MDVR, '(vacio) -> CORWIN') figura como corregido y el sintoma volvio igual en el 24: se arreglo el caso que se vio, no el mecanismo. Pertenece a la clase de [[reference_agrupar_items_por_sintoma_manda_a_una_reimportacion_lo_que_la_reimportacion_no_puede_tocar]]. Lo que hay que decidir antes de tocar codigo, y es una pregunta de datos, no de UI: si carroceria_fabricante y carroceria_modelo son el mismo hecho con dos nombres, sobra una columna y hay que portar y borrar; si son hechos distintos, el import tiene que llenar las dos o el diff no puede mirar la que el import no escribe. No es un arreglo de renderer. Antes de cerrar hay que censar las demas columnas con la misma forma: cualquier campo que la app escriba y el import deje NULL produce exactamente este falso cambio en la primera edicion. El censo es el entregable, no el parche de carroceria.