feat(wiki): el tema de agrupacion sale de subject a su propia columna

[wolverin0]

El problema

wiki_engine._load_claims_by_topic agrupaba artículos por subject. Pero subject es el sujeto de una tripleta, y tres mecanismos independientes lo tratan como identidad:

• idx_claims_public_confirmed_tuple_unique sobre (tenant, subject, predicate, scope)
• auto_resolver.py:224 — agrupa conflictos por esa misma tripleta
• conflict_resolver.py:1 — "two claims share the same subject and predicate but differ in object_value" → contradicción, supersede una

Por eso wiki-absorb sólo podía correr con --pinned-only: sobre el corpus entero o colapsaba todo en un único artículo general, o había que engrosar los subjects — y eso hacía que el steward archivara claims no relacionadas en el ciclo siguiente.

Medido antes de escribir nada: engrosar subjects producía 176 colisiones directas del índice único sobre 13.767 asignaciones. Y esas eran sólo las que la base frenaba; el resto habría llegado vivo hasta el resolver.

El cambio

topic TEXT, columna aditiva y deliberadamente sin unicidad. El motor agrupa por COALESCE(NULLIF(topic,''), subject, 'general').

• Backward compatible: las claims sin topic siguen saliendo por subject, comportamiento idéntico al actual.
• Migración con el idioma establecido del repo (ALTER TABLE ADD COLUMN + duplicate column name tolerado), verificada en base nueva y en base vieja, e idempotente.
• schema.sql y schema_postgres.sql actualizados según el contrato de Boundaries.

Evidencia

	antes	después
Claims vivas agrupadas	3.252 (18%)	16.958 (96%)
project:memorymaster	1 artículo general	319 artículos, el mayor de 95 claims

Los 3.864 sin topic son los OTHER que preferí no forzar (612) más los 3.252 que ya agrupaban bien por subject — el fallback haciendo su trabajo.

Migración sobre la base viva de 6,9 GB: 0,14 s, quick_check ok, 142.345 claims intactas.

Tests

tests/test_wiki_groups_by_topic_not_subject.py — anclados en el requisito, no en la implementación. El último falla si alguien le agrega unicidad a topic, que es lo que reintroduciría el problema.

Barra roja verificada: con el esquema puesto pero revirtiendo sólo la lógica de agrupación, los 3 tests del requisito fallan y los 2 de compatibilidad siguen pasando.

Nota: el MCP de GitNexus no conectó en esta sesión (CONNECTION_CLOSED), así que el radio de impacto se midió con grep en vez de gitnexus_impact: una función interna, un llamador (_absorb_impl), y tests/test_wiki_absorb_pinned_only.py que ya la ejercita — pasa sin cambios (11/11 con los nuevos).