Cadena entidad -> linea -> vehiculo: mover linea_id y entidad_id fuera de vehiculo_historial a una relacion de estado actual

Decision de esquema de Elazar, 2026-08-31, relayada por db03-mba-l-ca y confirmada en paralelo por pm-mba-l-cc. PENDIENTE de confirmacion directa de Elazar: llego por dos relays, no de el a mi. Es prerequisito de 'historial de usuario en cero al handoff' (MOVILBA-155). LA DECISION: la propiedad de un vehiculo se deriva por la cadena entidad -> linea -> vehiculo. NO hay relacion directa vehiculo -> entidad. Transferir una linea mueve todos sus colectivos; una venta individual mueve el vinculo vehiculo<->linea con expediente y fechas. El import establece la linea base normalizada ACTUAL en esa cadena; las filas del Excel quedan como provenance cruda y nunca se materializan como historial de usuario. POR QUE ES PREREQUISITO (medido por mi contra PROD 2026-08-31, SELECT): - La UNICA relacion vehiculo<->entidad que existe hoy es la FK vehiculo_historial.entidad_id -> entidades. No hay ninguna columna de entidad ni de linea en vehiculos ni en vehiculos_datos_colectivos (la unica parecida es vehiculos_datos_colectivos.identidad_id, que es otra cosa). - vehiculo_historial es hoy el portador de linea_id, entidad_id, estado_id, motivo_id, tramite_id, vehiculo_id. - v_vehiculos_hist_ultimo lee FROM vehiculo_historial, y v_vehiculos_lineas_entidades se arma juntando vehiculos + entidades + lineas A TRAVES de esa vista. => Vaciar vehiculo_historial ANTES de que exista y este poblada la cadena nueva destruye la unica asociacion vehiculo-entidad y vehiculo-linea del sistema. El orden no es preferencia, es correccion. ALCANCE DEL IMPACTO (PROD): vehiculo_historial tiene 4225 filas (DEV 4338). Dependen de ella 11 vistas - v_vehiculo_historial, v_vehiculo_cadena, v_vehiculos_hist_ultimo, v_vehiculos_detalle, v_vehiculos_export, v_monitor_historial_anomalias, v_db_users_footprint_detalle y cuatro v_audit_* - mas 1 trigger. FKs entrantes: 0, asi que no hay integridad referencial que se rompa. En el codigo la tocan 11 archivos: src/actions/vehiculos.ts, src/lib/historial-vehiculo.ts, src/repositories/{vehiculos,parque-movil}.ts, src/services/vehiculos.ts, src/types/vehiculos.ts, src/components/ExpedienteForm.tsx, src/app/vehiculos/[id]/page.tsx, las dos rutas /api/vehiculos/[id]/{entidad,linea}/history y src/lib/openapi/components.ts. CONSECUENCIA QUE NADIE LEVANTO TODAVIA: la API de Rendiciones que shipee HOY (MOVILBA-144, v5.4.78+) lee v_vehiculos_lineas_entidades. Si se vacia el historial antes de poblar la cadena nueva, esa API responde 200 con entidad y linea vacias - no falla, MIENTE. Es consumidor externo con key ya minteada. SECUENCIA OBLIGATORIA: (1) diseñar y crear la relacion de estado actual; (2) poblarla desde el libro; (3) reapuntar las 11 vistas y el codigo; (4) recien ahi tocar el historial. Nunca al reves. REGLA QUE SIGUE VIGENTE Y NO LA TOCA ESTA DECISION: Baja es un ESTADO, no un borrado, y DELETE / DISABLE TRIGGER sobre vehiculo_historial esta prohibido aun con GO. 'Historial en cero' se tiene que lograr no proyectando el libro adentro, no borrando lo que hay - salvo que Elazar diga explicitamente otra cosa. TAMBIEN AFECTADO: MOVILBA-42/76 (append-only vs una-fila-viva) y MOVILBA-99 (derivar historial del diff de columnas) asumen que el historial es el portador. Hay que re-leerlos contra esta decision antes de seguir cualquiera de los dos. MOVILBA-157 (verificacion post-import de AG986KG en historial) tambien depende de que quede historial que verificar.