Cuatro afirmaciones falsas en los comentarios de informe-query.ts, una de ellas argumentando a favor del denominador por categoria que TERRA-178 acaba de prohibir

CUATRO AFIRMACIONES FALSAS EN LOS COMENTARIOS DE src/lib/informe-query.ts, encontradas por audit-terra-ca en una lectura acotada a ese archivo en 13fedc2 y verificadas UNA POR UNA contra la fuente y contra la base antes de abrir esta fila. Ninguna es defecto de comportamiento; las cuatro son afirmaciones que alguien va a leer para decidir algo. 1. CONTEO FALSO. La linea 11 dice "The seven filters narrow a set of practicas once". FILTER_SQL tiene NUEVE predicados, $1 a $9: desde, hasta, modulo, cirugia, complicacion intra, complicacion post, tipoInjerto, marcaImplante y alumno. Los conte en la fuente. 2. MEDICION VENCIDA, Y LLEVA FECHA. La linea 29 dice "Measured live 2026-08-23: 6 campos, 4 distinct categories". Medido hoy contra la base: 6 campos y CINCO categorias vivas - terraMarcaImplante, terraTipoBarreraImplante, terraTipoBarreraReconstruccion, terraTipoInjerto y terraZonaDadora. La cuarta se volvio quinta cuando se partio tipoBarrera en las variantes de Implante y Reconstruccion. LO INTERESANTE ES QUE ESTE COMENTARIO HIZO TODO BIEN: declaro que era una medicion, la fecho, y nombro contra que se midio. Igual quedo vencido sin que nada avisara. Fechar una medicion la vuelve auditable; no la vuelve auditada. 3. DEMASIADO AMPLIA DESPUES DEL ARREGLO, Y ES LA QUE PUEDE REINTRODUCIR EL DEFECTO. Las lineas 25-29 justifican indexar por lookupCategory en vez de por campo id porque agrupar por campo id "would split one clinical question across two rows". Eso sigue siendo cierto PARA LAS FILAS DE VALOR, que es lo que hace campoBreakdown. Es falso leido como regla del reporte entero, porque la aplicabilidad tiene que resolverse POR campoId - es literalmente lo que TERRA-178 construyo y lo que su spec tuvo que corregir. Un comentario que argumenta a favor de la categoria, sin distinguir cual de las dos consultas, invita a escribir exactamente el denominador por categoria que la fila prohibio. Hay que separar las dos frases: la distribucion de valores agrega sobre la categoria compartida, la aplicabilidad se resuelve por campo. 4. IMPOSIBILIDAD AFIRMADA QUE NO ES LA RAZON. Las lineas 111-113 dicen que sin resolver por campoId "a practica que puede ver los dos seria contada dos veces". Una practica NO PUEDE ver los dos: los dos campos tipoInjerto estan en modulos distintos, una practica tiene un solo moduloId, y campoApplicable une por kc."moduloId" = f."moduloId". El DISTINCT no sostiene ese caso porque ese caso no existe. Sigue siendo correcto tenerlo - es defensivo y queda a salvo si alguna vez dos campos del MISMO modulo comparten categoria, que hoy no pasa - pero la razon escrita no es la razon real. Y esa frase la dicte yo en la spec, asi que el error es mio antes que de quien la escribio. POR QUE VA EN FILA Y NO SOLO EN UN DM: TERRA-178 esta cerrada y no la reabro. Sin fila, cuatro correcciones acordadas en un hilo de mensajes desaparecen cuando el hilo desaparece, que es como sobrevivieron los otros comentarios vencidos que aparecieron hoy. ALCANCE: correccion de comentarios unicamente. Ninguna de las cuatro cambia una linea de codigo, y si alguna parece pedir un cambio de codigo, eso es un hallazgo nuevo y va aparte. NO HALLAZGO, registrado para que nadie lo vuelva a mirar: las lineas 137-144 limitan correctamente el lenguaje de isActive/deletedAt sin filtrar a la resolucion de ETIQUETA, y no excusan incluir filas de valor borradas blando - eso es TERRA-180 y sigue siendo suyo. Y el comentario amplio de :159-161 sobre que todo sale del mismo f no afirma nada falso, aunque los denominadores de campo describan a proposito un subconjunto.