fix(profile): el reduce va por lotes y un run a medias es reanudable

[wolverin0]

El bloqueo

El reduce pasaba todos los candidatos de un run en una sola llamada, contra un validador (providers.py:108) que exige partición perfecta: cada candidate_id exactamente una vez, sin duplicar ni omitir.

Run	Candidatos	Desenlace
2	68	completó
3	234	clavado en reducing desde el 2026-08-20

Diez días de corridas programadas más cuatro reintentos medidos a mano, alternando entre profile candidates must appear exactly once y JSON malformado. El perfil inyectado en cada SessionStart quedó con hechos del 6 al 9 de agosto.

Por qué la columna va primero

Lotear sin marcar consumidos habría sido peor que el bloqueo: apply_decisions relee candidates(run_id) entero en cada llamada (repository.py:296), así que un lote aplicado y un crash antes del siguiente dejaba los mismos candidatos listos para aplicarse de nuevo — hechos duplicados en el perfil que entra en cada sesión.

• Migración 23: compiled_profile_candidates.consumed_at, sin unicidad, índice (run_id, consumed_at). Filas previas en NULL a propósito: un run en vuelo debe ver sus candidatos como pendientes.
• candidates(run_id, pending_only=True) filtra lo consumido.
• apply_decisions marca dentro de la misma transacción que aplica la decisión, con AND consumed_at IS NULL.
• _reduce_and_complete loopea sobre lotes de reduce_batch_size (40, MEMORYMASTER_PROFILE_REDUCE_BATCH), releyendo active_facts() entre lotes para que el lote N+1 fusione contra los hechos del N.
• Un lote que no consume nada corta con error en vez de loopear infinito.

Semántica, dicho explícito: las fusiones se deciden con visibilidad parcial, así que dos candidatos de lotes distintos pueden quedar como dos hechos donde una partición única los unía. Es el precio, y es preferible a no reducir nunca.

Evidencia en la base viva

El primer intento consumió 120/234 y falló en el cuarto lote — y los tres lotes previos quedaron. Antes ese mismo fallo tiraba todo, que es por qué diez noches seguidas terminaron igual. El reintento siguiente drenó los 114 restantes:

	antes	después
Run 3	reducing, 10 días	completed
Hechos activos	29	52
Viñetas en la proyección	32	50

Techo del perfil: 800/40 → 1400/60

Va en el mismo commit porque el fix lo destapa: con 52 hechos el techo viejo cortaba 20 en silencio y la proyección quedaba clavada en 800/800 — justo cuando los hechos nuevos eran los buenos (memorymaster and UNMS CRM sup=10, WISP, Task Scheduler, ARS) y los viejos los stale (Godot battle royale). Truncar por techo no avisa.

Barra roja

Revirtiendo sólo el filtro de pendientes, la suite se cuelga hasta el timeout en vez de fallar un assert: el bucle relee los mismos 234 para siempre. Ese es exactamente el modo de falla que el filtro evita.

49/49 en tests de perfil, ruff limpio, inyección en SessionStart verificada en vivo (50 viñetas, marcador presente).

Nota: el MCP de GitNexus sigue sin conectar en esta sesión (CONNECTION_CLOSED), así que el radio se midió con grep — candidates() y apply_decisions tienen un solo llamador cada uno dentro de profile/.