docs(orquestador): tope de fan-out duro = 6 ejecutores por orquestador

El doc hablaba de "tope de fan-out para no explotar la flota" sin numero. Se
fija un maximo DURO: 6 ejecutores role=executor activos simultaneos por
orquestador. Al alcanzarlo, el orquestador no lanza mas: encola las sub-tareas
restantes hasta que un slot se libere (ejecutor verificado met + kill_fleet_agent).

Justificacion: ya hubo el caso de 30 agentes que no cerraban nada y, al competir
todos por el mismo rate-limit compartido, hubo que desactivar goal_refine. Mas
ejecutores no es mas throughput; el cuello de botella es el rate-limit compartido
y los DoD que nadie cierra.

Escrito en el splitter + regla dura de orchestration.md (detalle + justificacion)
y en las reglas duras del command (numero + encolado, puntero al detalle).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

.claude/rules/orchestration.md

@@ -242,7 +242,16 @@ secuenciales encadenadas), **siempre dentro del tope de fan-out** (ver "Tope de
 
 ### Tope de fan-out (regla dura)
 
-Para no explotar la flota.
+**Máximo 6 ejecutores `role=executor` activos simultáneos por orquestador.** Si se alcanza el tope,
+el orquestador NO lanza más: **encola** las sub-tareas restantes y las despacha a medida que un slot
+se libera — un slot se libera cuando un ejecutor se verifica `met` y se cierra con `kill_fleet_agent`
+(auto-kill). El conteo es de la **familia propia** (ejecutores con tu `parent_orchestrator`), no de
+toda la flota; resuélvelo con el routing por `parent_orchestrator`, igual que el push activo.
+
+Por qué un número duro y no "los que hagan falta": ya hubo el caso de **30 agentes que no cerraban
+nada** y, al competir todos por el mismo rate-limit compartido, hubo que desactivar `goal_refine`
+(el hook que reescribía el `dod` con un LLM por prompt). Más ejecutores no es más throughput: el
+cuello de botella es el rate-limit compartido y los DoD que nadie cierra, no el número de procesos.
 
 ### Cadencia