La pantalla de editar pedia /api/vehiculos/<id>/tipo, que no existe: 404 en cada edicion y dos ramas a rutas inexistentes

MEDIDO por proxy-mba-w-cc en dev01 el 2026-09-07, editando AE801OE: la consola tira 'Error detecting vehicle type: ClientError' y el request es GET /api/vehiculos/4002/tipo, que vuelve una pagina 404 en HTML y el apiClient parsea como ClientError. LA RUTA NO EXISTE. src/app/api/vehiculos/[id]/ tiene entidad, estado, historia, linea y route.ts, nada mas. O sea el fetch fallaba SIEMPRE, no a veces, desde que se escribio. POR QUE PASO DESAPERCIBIDO, y es la parte que importa: el catch redirige a /editar/colectivo, que es EXACTAMENTE el mismo destino al que llegaban las cuatro ramas del if. La pantalla andaba bien. El unico sintoma era una linea de consola y un request 404 en cada edicion. Un camino de fallo que aterriza donde aterriza el exito no se distingue del exito. Y habia un defecto latente adentro: dos ramas apuntaban a /vehiculos/<dominio>/editar/taxi y /editar/remis, que TAMPOCO existen - solo existe editar/colectivo. Si la ruta de tipo hubiera contestado alguna vez 'taxi', el usuario terminaba en un 404 de verdad. La rama muerta tapaba a la otra. ARREGLO (v5.5.18): se retira la deteccion entera y el redirect va derecho a colectivo, mas los imports que quedaron sin uso (apiClient, connectionHandler, createEndpoint). Cuando exista un segundo formulario, la eleccion sale del tipo que ya trae la resolucion del dominio, no de una llamada extra. NO EJERCITADO: nadie conto cuantos 404 de estos hay en los logs, ni si otras pantallas piden rutas que no existen con el mismo patron try/catch-que-aterriza-en-el-mismo-lugar. Eso es una barrida aparte y vale la pena.