MOVILBA-552 introdujo una regresion: despues de una BAJA el periodo vigente cae en la fila IMPORT abierta e inmutable y el vehiculo vuelve a leerse ALTA

REGRESION MIA, en DEV y PROD desde bb1a4341 (09-23). Medida por audit-mba-l-ca sobre la base sin editar: tools/movilba-344-writer-rehearsal.ts falla en la pata BAJA, linea 629. Antes de la BAJA el sucesor APP abierto elegido es id 286466; la BAJA lo cierra; y entonces el nuevo orden canonico por vehiculo elige la fila IMPORT abierta e inmutable 275223, asi que estado_derivado vuelve a ALTA. Un vehiculo al que se le acaba de dar de baja se lee como ALTA. CAUSA EXACTA, y no es la particion: es el ORDER BY. El cuerpo viejo ordenaba por GREATEST(COALESCE(fecha_baja,fecha_alta),fecha_alta) DESC primero - o sea por RECENCIA - y ahi la fila APP recien cerrada gana, porque su fecha_baja es de hoy y es mayor que la fecha_alta de la fila import. Ademas llevaba (origen='app') DESC como desempate. El cuerpo nuevo arranca con (fecha_baja IS NULL) DESC - o sea por APERTURA - y una fila import abierta le gana por construccion a cualquier fila app cerrada, sin importar las fechas. Cambie el orden de precedencia entre recencia y apertura sin medir ese caso. LO QUE ESTO CONTRADICE, ya estaba escrito: la vista de periodo vigente desempata a favor de la fila de app, y la fila del app es un overlay de la fila importada inmutable - dos periodos abiertos son el DISENO, no una anomalia. El monitor lo dice igual: v_monitor_historial_anomalias solo llama MULTIPLES_ABIERTOS al par app+app; el overlay import+app es legitimo. Yo tome 'una sola fila abierta' como invariante y nunca lo fue. LA PREGUNTA QUE HAY QUE MEDIR ANTES DE TOCAR NADA: el desempate canonico de TypeScript (vehiculos.ts:268, parque-movil.ts:157 y la lateral cur_fa de v_vehiculos_detalle) TAMBIEN arranca con (fecha_baja IS NULL) DESC y NO tiene termino de origen. O esos tres resolutores tienen el mismo defecto y nadie lo vio, o nunca ven una fila import abierta junto a una app cerrada. Hay que censar: cuantos vehiculos en PROD y en DEV tienen HOY una fila import abierta y ademas una fila app cerrada mas reciente. Ese numero es el alcance real de la regresion y decide si el arreglo es solo de la vista o de los cuatro resolutores. NO se arregla subiendo (origen='app') DESC solo en la vista: eso vuelve a separar la vista de los tres resolutores de TS, que es exactamente la clase de defecto de los cuatro resolutores. El arreglo tiene que dejar a los cuatro con el mismo orden. Alcance: audit sigue con MOVILBA-557 y NO disena el arreglo de la vista. Este item es del carril de codigo.