Validación multi-repo de referencias en fuentes wiki

Problema

El sistema de lint/reclaim de la wiki Supercontexto validaba referencias a código (sources.code[].ref) contra un único repositorio hardcodeado: CreaRackSL/CreaRack-Pro.

Esto causaba falsos negativos críticos: las 11 páginas wiki que documentaban código del CreaRackSL-workspace (handlers MCP, drift.ts, scripts, crons) reportaban 404 y quedaban marcadas como stale de forma permanente. El proceso reclaim nunca podría recuperarlas porque no encontraba las fuentes.

Impacto:

• Pages aisladas de workspace documentadas pero irrecuperables
• Confiabilidad de lint/reclaim cuestionada
• Duplicación de lógica de validación en 3 funciones distintas

Decisión

Crear una función auxiliar sourceRefExists(ref, ghPat) que:

1. Intenta el repo predicho según repoForSourcePath() (heurística del drift-check que acierta ~95% de veces)
2. Fallback al otro repo si el primero falla
3. Devuelve consumo de fetches para que cada caller ajuste su presupuesto de subrequests (CF Workers tiene límite ~50)

Reemplazar los 3 bloques de fetch hardcodeados en:

• wikiLintCheck() — chequeo de fuentes en operaciones de actualización
• wikiLintBulk() → pass sources — chequeo de todas las pages en batch
• wikiLintBulk() → pass reclaim — validación antes de recuperar pages stale

Rationale

• Reutilización: repoForSourcePath() ya existe (drift-check), no reinventar
• Eficiencia: predicción correcta → 1 fetch (98% de casos); fallo → 2 fetches (ambos repos)
• Robustez: fallback empírico evita false positives sin perder cobertura
• Presupuesto acotado: cada fetch se descuenta del límite de subrequests
• Recuperación: 11 pages del workspace ahora pueden ser recuperadas por reclaim

Consecuencias

✅ Positivas:

• Pages del workspace con drift real ahora se validan correctamente
• Lint/reclaim pueden actuar sobre el conjunto completo de pages (Pro + workspace)
• Una sola función de validación centraliza la lógica
• Coste medio: 1 fetch por fuente (vs 1 antes, pero correcto)

⚠️ Trade-offs:

• Fallback a segundo repo consume extra fetch en ~5% de casos (ambigüedad de prefijos: scripts/, .github/, etc.)
• Presupuesto de subrequests puede apretarse si hay muchas fuentes rotas
• Requiere que repoForSourcePath() esté sincronizado con la estructura real de ambos repos

Bonus

Se normalizaron 5 líneas largas preexistentes con prettier:

• Formatting de argumentos en ghPutFile() (3 calls)
• Ternario en asignación de actor y reclaimLimit
• Cálculo de estimatedCostUsd (paréntesis para claridad)

Véase también

• [[entity—biblioteca—service—wiki-handlers-crud]]
• [[entity—biblioteca—handler—bib-check-drift-for-doc]]
• [[decision—20260514—kb-vs-graph-drift-detection]]
• [[entity—biblioteca—table—bib-drift-checks]]
• [[concept—biblioteca—source-validation]]