DROP de public.parque_rutap_temp en DEV y PROD: staging del import viejo, sin lector, 1601 filas

APLICADO Y COMMITEADO 2026-09-18. Se abre despues del hecho porque el trabajo salio etiquetado como MOVILBA-504 y 504 es OTRA cosa: el port del cleanup de carrocerias a PROD, que sigue abierto. Cerrar 504 habria cerrado la poda. Lo caza audit-mba-l-cc. Que se hizo: DROP ... RESTRICT de public.parque_rutap_temp en las dos bases. 1601 filas cada una. Era staging del camino de import VIEJO; el importer actual escribe rutap.snapshots / rutap_rows y no la toca. Aparecio porque tenia 566 ids apuntando por VALOR (sin FK) a carrocerias marcadas para borrado fisico - invisible a pg_constraint, que es por que el gate de uso no puede ser solo FKs. GO: Elazar en CLI, literal '1a', sobre la pregunta de una linea con las filas, las cero escrituras y los cero dependientes adentro. DEV no pidio GO (descartable). Siete instrumentos en el PRE, cada uno con su cero: pg_depend/pg_rewrite, pg_get_functiondef, pg_views.definition, pg_matviews.definition, pg_policies, pg_constraint (las dos direcciones), pg_trigger. Dos respuestas independientes de blackboard (audit y db02), las dos A, las dos con la misma correccion a la premisa. NO cubierto, y queda dicho: pg_stat_statements no esta instalado en PROD, asi que los 1280 seq_scan de 127 dias no se atribuyen a una consulta. Lo que decide es la comparacion - el andamiaje hermano lee 976/934/787 y en DEV toda la familia lee 10-11 parejo, firma de barredor de esquema - mas cero escrituras en 127 dias. Archivos: docs/migrations/2026-09-18-movilba-504-drop-parque-rutap-temp-DEV-Y-PROD.sql (nombre con el ref equivocado, se corrige el header en su propio commit), 79f92b93 y 21e1a91c. MOBAAPI-649 repuntado al libro vigente por comentario en Jira antes del apply.