Comentarios en src que afirman conteos vivos: 35 cirugias/0 confirmed es hoy 78/48/17 y users 3 es 159 - el numero vencido y la conclusion son dos preguntas separadas

Censo de coder-terra-ca sobre src/**, acotado a comentarios que afirman un CONTEO o una EXHAUSTIVIDAD sobre datos vivos o sobre la fuente. Devolvio unos 60 comentarios en unos 30 archivos. La lane no tiene acceso a la base y lo dijo: marco TODA afirmacion de origen DB como no verificada, incluso las que citan fecha y autor. Eso es correcto y es lo que la hace util - entrego la lista, no un veredicto. Las medi yo contra la base viva; lo que sigue son numeros de hoy, no del censo. LO QUE MEDI Y ESTA MAL, Y NO ES POR POCO. terraCirugias: 78 filas totales, 48 con isActive, 17 con isConfirmedByClient. Hay al menos DIEZ comentarios en src que dicen "35 cirugias" y "0 confirmed" - lookups.ts:32, :310, practica-form.tsx:64-65, :191, nueva/page.tsx:74, administrar/page.tsx:34-36, mi-cursada/page.tsx:125, cirugias/page.tsx:27, practica-zona-core.ts:20, practica-zona-core.test.ts:29, :87. Ninguna de las tres definiciones posibles da 35, o sea que no es ambiguedad de predicado: el numero esta vencido a secas. Y "0 confirmed" es hoy 17, que es la mitad que mas importa porque describe un ESTADO DEL PROCESO del cliente, no un tamaño de catalogo. Un comentario que dice que el cliente no confirmo nada, cuando confirmo 17, invita exactamente a la conclusion contraria a la real. users: 159 filas vivas. Hay tres archivos que dicen 3 - access-request-core.ts:7-8, email/recipient-guard.ts:33-34, email/recipients.ts:35-36 - y vUserGroups, que uno de ellos declara de tres filas, tiene 170. PERO ACA ESTA LA PARTE QUE CAMBIA EL TRABAJO Y QUE NO SE VE MIRANDO LA LISTA: EN LOS TRES, EL NUMERO SE VENCIO Y LA CONCLUSION SOBREVIVIO. Lo medi una por una en vez de asumir que un premisa falsa arrastra la conclusion. - access-request-core.ts argumenta que requestTerraAccess NO TIENE LLAMADOR POSIBLE porque hace falta un usuario vivo con CERO membresias terra y no existe ninguno. Medido hoy: de las 159 filas vivas, las que NO tienen membresia terra son CERO. El camino sigue sin llamador. La premisa se multiplico por 53 y la conclusion aguanta. - email/recipients.ts apoya su decision en una CARDINALIDAD, no en un total: "vUsersAdmin cruzado con terra/admin da exactamente UNA fila", y de ahi que leer la base y hardcodear una direccion sean indistinguibles. Medido hoy: terra/admin sigue en 1. La propiedad que sostiene la decision esta intacta. Lo que si se movio en ese mismo parrafo es terra/docente, que paso de 1 a 26, y terra/alumno, que hoy es 141. - email/recipient-guard.ts dice que el piso de filtrado es a proposito MAS ANCHO que lo que terra observo, y que la lista esta vacia de entradas derivadas de terra porque enamel no sembro sinteticos, no porque se hayan inspeccionado y no distingan. Medido: sigue habiendo cero usuarios sinteticos vivos. El razonamiento es el correcto y el numero viejo no lo toca. DE AHI SALE LA REGLA DE ESTA FILA, y es distinta de la de TERRA-188: EL NUMERO VENCIDO Y LA CONCLUSION SON DOS PREGUNTAS SEPARADAS Y HAY QUE HACER LAS DOS. Corregir el numero y no re-verificar la conclusion deja una afirmacion vieja con numero nuevo, que es peor que antes porque ahora parece medida. Y al reves, tirar la conclusion porque el numero se vencio destruye razonamiento que sigue siendo valido - los tres casos de arriba lo habrian perdido. Y LOS TRES ESTAN FECHADOS - "medido por db-terra-cc el 2026-08-01" - que es la forma correcta que TERRA-188 defiende. O sea que la forma correcta funciono: se puede ver de un vistazo que son de agosto y decidir re-medir. Lo que ninguno tiene es un DISPARADOR. access-request-core hasta escribe su propia condicion de vencimiento - "una membresia removida, o una cuenta nueva, vuelve vivo el camino sin aviso y sin deploy" - y entraron 156 cuentas nuevas sin que nada mirara esa linea. La condicion de expiracion escrita no es un instrumento; nadie la lee en el momento en que se cumple. DEFECTOS DE DEFINICION que el censo aisla bien y que hay que arreglar aunque el numero se actualice, porque sin predicado el comentario no es reproducible: "las 33 filas del catalogo" no nombra tabla ni predicado de borrado (medi antecedentesCatalog = 33, o sea hoy da, pero por casualidad de que nadie borro); los comentarios de zona se contradicen entre 48 y 35 y ademas hablan de una columna zonaAplica que NO EXISTE en terraCirugias - las columnas son id, nombre, moduloId, requierePieza, requiereRegion, isActive, isConfirmedByClient, createdAt, deletedAt - asi que ahi hay que leer que quisieron decir antes de medir nada; y practica-form dice que regiones esta "terra-scoped a 6" mientras lookups:332 dice que regiones NO tiene scope y que seis es el tamaño de la semilla, que son dos mecanismos distintos escritos como si fueran el mismo. UNO QUE MEDI Y ESTA BIEN, para que nadie lo "arregle": terraModulos = 6, o sea que toda la familia "6 modulos" es exacta hoy. Y profilePictureRef sigue en cero filas no nulas, que es lo que dicen mi-perfil/page.tsx:96 y telefono-form.tsx:19. UN HALLAZGO DE FUENTE, no de base, que el censo encontro solo: instrumentation.ts:3-4 afirma que grepear recordPoolIdentityOnce en src devolvio "exactamente un hit, su propia definicion". Hoy hay seis hits textuales. Es una medicion historica redactada en presente - la misma clase que TERRA-188 - pero se verifica leyendo src, no la base. ALCANCE DECLARADO POR EL CENSO Y QUE NO HAY QUE OLVIDAR: es solo fuente. No ejercito deploy, ni definiciones de base o RPC, ni caminos de navegador. Sus PASS dicen "la fuente no se contradice", no dicen que el comportamiento sea el afirmado. PROCEDENCIA: censo de coder-terra-ca (tag coder-terra-ca-mti74fsee6su), pedido por mi. Sin commits y sin cambios de codigo, como se pidio. Las mediciones contra la base viva son mias.