normalizar_si_no no saca chr(13), asi que un valor con retorno de carro sigue resolviendo a NULL

Medido por audit-mba-l-cc el 2026-10-08 auditando MOVILBA-340: el conjunto de caracteres que rutap.normalizar_si_no saca NO incluye chr(13), asi que E'SI\r' sigue devolviendo NULL. Es la UNICA instancia sobreviviente de la clase de defecto que 340 existe para cerrar, y no es hipotetica en este libro: el proyector ya saca [\r\n] de los seriales de chasis y de motor, o sea el \r es un peligro conocido y ya tratado en OTRO camino del mismo pipeline. Que 340 no lo cubra no es un descuido de alcance, es un hueco en el centro del alcance. NO se arregla dentro de 340: ese archivo tiene PASS sobre ca08f209 y tocarlo ahora invalida el pin y obliga a re-auditar todo el archivo por un caracter. Va aparte, con su propio veredicto, y el orden correcto es aplicar 340 primero y este despues, porque el segundo reemplaza la misma funcion que el primero crea. Antes de escribirlo, medir: cuantas celdas si/no del libro vigente contienen chr(13) hoy (db03 midio 5 valores crudos distintos y ninguno con NBSP, acento ni padding, pero ese conteo no dice nada sobre \r), y si alguna llega por un camino distinto del de los seriales. Si el conteo vivo es 0 sigue siendo un silent-NULL latente que hay que cerrar, igual que la mitad si/no de 340, y se dice asi en el reporte en vez de venderlo como un arreglo de filas.