Quedan dos LIMIT 1 sin ORDER BY en rendiciones (findEmpresaByCuit y findLineaByNumero): la clase que arreglo MOVILBA-273 solo se corrigio en el lector por dominio

Encontrado por coder02 el 2026-09-08 al cerrar MOVILBA-273 contra origin/dev ed141006 (v5.5.80). 273 arreglo findColectivoByDominio y su ultima linea pedia revisar la MISMA FORMA en el resto del archivo; la revision es esta y queda un residuo. src/repositories/rendiciones.ts:231 findEmpresaByCuit hace WHERE e.borrado_en IS NULL AND e.cuit = $1 LIMIT 1, y :243 findLineaByNumero hace WHERE borrado_en IS NULL AND numero_linea = $1 LIMIT 1. Ninguno tiene ORDER BY. Un LIMIT 1 sin ORDER BY no elige: devuelve la fila que el plan traiga primero y puede cambiar entre dos corridas iguales sin que nada falle - identico al mecanismo de 273, en otro par de lectores. NO ESTA MEDIDO SI HOY HAY ENTRE QUE ELEGIR, y esa es la pregunta que decide si esto es un defecto de cara al usuario o solo una consulta no determinista: hace falta saber si existe un indice unico sobre entidades.cuit y sobre lineas.numero_linea restringido a las filas vivas (borrado_en IS NULL), en DEV y en PROD por separado, mas el conteo de cuit repetidos entre entidades vivas y de numero_linea repetidos entre lineas vivas. En 273 la garantia resulto venir de uq_vehiculos_dominio_active, un INDICE y no la consulta, y aun asi se ordeno: mismo criterio aca. Ojo con MOVILBA-220, que dice que faltan lineas en PROD - la poblacion de lineas no es la misma en los dos entornos. La API de Rendiciones esta viva en produccion desde el 2026-09-02 (MOVILBA-187).