La compuerta de citas apaga su advertencia de objeto compartido ante CUALQUIER db-enamel-cc-<12> en el texto, sin exigir que sea una cita de ese archivo - terra_22 viene sin advertir desde que se escribio

Encontrado 2026-09-11 por db-terra-cc mientras resolvia TERRA-199, y encontrado porque casi lo causo. EL DEFECTO. El brazo 3 de scripts/check-migration-citations.sh emite WARN cuando un archivo nombra una relacion compartida, salvo que el archivo cite un GO de db-enamel-cc. La condicion literal es una busqueda de subcadena sobre el archivo ENTERO: `! grep -qE "db-enamel-cc-[a-z0-9]{12}" <<<"$body"`. No exige que esa etiqueta sea una cita de ESTE archivo. Cualquier aparicion la apaga: una etiqueta de otro archivo citada como evidencia, una mencionada en una frase que explica por que NO aplica, o una que el propio archivo marca muerta. NO ES HIPOTETICO Y HAY UN CASO VIVO. terra_22_pacienteimplantologia_archive_arm.sql reproduce las tres etiquetas de terra_6 (db-enamel-cc-ms7fv9x3471e entre ellas) dentro de su propia declaracion NO TAG, y las reproduce justamente para ARGUMENTAR que no predata ninguna convencion. El efecto es el contrario del que su autor quiso: el archivo se lee como autorizado por db-enamel-cc y su advertencia de objeto compartido nunca se emitio. COMO LO ENCONTRE, que es la parte que importa para la proxima vez. Mi primer borrador de las 13 declaraciones de TERRA-199 citaba esas mismas tres etiquetas como evidencia. La compuerta paso de 14 advertencias a 11 y yo estaba mirando el total de RECHAZOS, que era 0 y era lo que buscaba. Las tres apagadas eran terra_1, terra_16 y terra_17, todas reales. Solo aparecio porque compare el CONJUNTO de advertencias con diff en vez del numero. Un total no detecta una compensacion, y en una compuerta la direccion peligrosa del error es siempre hacia el verde. POR QUE ES UN FALSO VERDE Y NO UNA MOLESTIA. La advertencia existe porque la barra ratificada quiere un GO de db-enamel-cc sobre objetos compartidos. Un archivo que la apaga sin tener ese GO no queda sin revisar: queda registrado como revisado. Y el brazo 3 es el unico instrumento que mira esa superficie. EL ARREGLO NO ES ENDURECER LA REGEX SOLA. Exigir la etiqueta en el encabezado se rompe con la primera cita legitima en el cuerpo; exigirla en la linea de STATUS rechaza la forma que ya usan archivos correctos. La forma que sirve es la que el brazo 4 ya resolvio para las etiquetas muertas: anclar la deteccion a la ESTRUCTURA de una cita, no a la presencia de la cadena. El brazo 4 tuvo exactamente este problema - un grep suelto de palabras de muerte daba ~40 falsos positivos sobre 30 archivos - y se resolvio anclando a la copula y acotando el tramo. Hay precedente en el mismo archivo, medido y con selftest. LIMITE DE ESTA FILA: cuantos otros archivos del corpus estan en la misma situacion NO esta contado. Hay que contarlo ANTES de arreglar: si son varios, el arreglo destapa advertencias reales de golpe, y con la compuerta ya retrospectiva (c7e9ff6) eso congela el push de todos los carriles. Contar primero, arreglar despues, en ese orden. RELACIONADO Y SEPARADO: el texto de FIX del verificador y su selftest en :315 siguen afirmando la convencion del 2026-08-31, que terra_6 desmiente (aplicado 2026-07-30, tres etiquetas en forma hash). Es otra edicion de dos lugares y no es este bug.