findColectivoByDominio elige con LIMIT 1 sin ORDER BY: en los 9 dominios duplicados de PROD la API de Rendiciones puede devolver la fila retirada

LEIDO POR coder02 el 2026-09-05 07:47 sobre origin/dev, a partir de la medicion de dominios duplicados de db02-mba-l-cc en MOVILBA-270/272. src/repositories/rendiciones.ts, findColectivoByDominio: 'WHERE d.dominio = $1 ... LIMIT 1' SOBRE v_vehiculos_detalle, SIN ORDER BY. Un LIMIT 1 sin ORDER BY no elige: devuelve la fila que el plan traiga primero, y eso puede cambiar entre corridas sin que nada falle. POR QUE NO ES TEORICO: PROD tiene 9 dominios con mas de una fila en public.vehiculos (19 filas, 10 retiradas) - medido por db02-mba-l-cc el 07:46 contra 10.78.42.168. Si v_vehiculos_detalle no filtra borrado_en, esos 9 dominios tienen dos filas candidatas y la API contesta una de las dos sin criterio. La API de Rendiciones esta VIVA EN PRODUCCION desde el 2026-09-02 (MOVILBA-187), o sea que un consumidor externo puede recibir el colectivo retirado en vez del vigente, y recibir uno distinto en dos llamadas iguales. LO QUE FALTA MEDIR ANTES DE ESCRIBIR CODIGO, una sola pregunta: v_vehiculos_detalle filtra borrado_en o no. Si filtra, no hay defecto de datos y queda igual el LIMIT 1 sin ORDER BY, que es un defecto por si solo. Si no filtra, es un defecto de cara al usuario en una API viva. EL ARREGLO, en cualquiera de los dos casos: elegir la fila VIVA explicitamente, no confiar en el orden del plan. Y ojo con el criterio de vivo: liveness de un vehiculo es estado_id, no borrado_en (regla permanente); para elegir entre dos FILAS de la tabla, la retirada es la que tiene borrado_en. Son dos preguntas distintas y hay que escribir la correcta. MISMA FORMA EN EL RESTO DEL ARCHIVO: revisar si otros lectores de rendiciones resuelven por dominio con LIMIT 1 y sin orden. NO EJERCITADO: no llame al endpoint; no mire el plan; no confirme si la vista filtra. Es lectura de codigo sobre origin/dev mas el conteo de db02 en PROD.