Decisión B (David 2026-07-04). El audit ultra encontró que el gate 5/7 de
submit_emergency_proposal era TAUTOLÓGICO: `council_size >= threshold(council_size)`
es siempre true, y solo exigía UN council member — así que un solo miembro
fast-trackeaba una propuesta a 48h (vs 14 días) sin la pre-aprobación 5/7.
Fix (flujo de dos fases, como anticipaba el propio doc "gather signatures then
promote"):
- FASE 1: `endorse_emergency_proposal` (nueva, call_index 12) — un council member
endosa por content-id (blake2 de title++body).
- FASE 2: `submit_emergency_proposal` ahora exige `live_endorsements >= 5/7 real`
(conteo EN VIVO, solo miembros aún en el council — consistente con el fix de
veto). Limpia los endosos consumidos tras promover.
+2 tests (flujo 5/7 completo con boundary 4→5, y regresión "un solo miembro NO
fast-trackea"). RUNTIME_VERSION 7→8 (call aditiva + metadata; TRANSACTION_VERSION
intacto). Workspace 284 verde.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>