El puntero de snapshot proyectado se lee con DOS predicados distintos: vehiculos.ts usa un MAX pelado sin origen ni borrado_en

Medido por coder02-mba-l-cc el 2026-09-10 sobre origin/dev, a raiz de que db03 va a publicar el snapshot 13. Hay DOS lecturas del mismo concepto -el ultimo snapshot proyectado- y no coinciden. (1) src/repositories/rutap-historial.ts:75 define LATEST_PROJECTED_SNAPSHOT_ID = max(rutap_snapshot_id) FROM rutap.vehiculo_historial_normalizado WHERE origen = import AND borrado_en IS NULL, con un comentario largo arriba que explica por que las dos condiciones son la DEFINICION y no un riesgo. Lo usan rutap-historial.ts:178 y vehiculos.ts:189. (2) src/repositories/vehiculos.ts:470-472 hace un SELECT MAX(rutap_snapshot_id) FROM rutap.vehiculo_historial_normalizado PELADO, en el ON de un LEFT JOIN, sin origen y sin borrado_en. POR QUE IMPORTA: el MAX pelado es mayor o igual al guardado, nunca menor. Si el tope tiene filas de origen app, o si las filas de import del tope estan borradas logicamente, las dos lecturas se separan y el LEFT JOIN de vehiculos.ts se ata a un snapshot en el que los lectores guardados no ven nada: la union no trae filas y los campos de historial salen vacios en esa pantalla, sin error y sin log. Los dos leen la tabla PROYECTADA, no la cruda, asi que esto no es el bug de 269; es el mismo puntero expresado dos veces. QUE HACER: vehiculos.ts:470-472 importa y usa LATEST_PROJECTED_SNAPSHOT_ID en vez de su propio MAX. Antes de tocarlo, MEDIR en DEV si hoy los dos valores difieren - si difieren, la pantalla ya esta mal y eso cambia la prioridad. NO ES UN GREP DE TS SUFICIENTE: el proyector rutap.proyectar_snapshot vive adentro de la base y hay que enumerar consumidores con pg_proc.prosrc, pg_views.definition y pg_depend antes de afirmar que no hay mas lectores.