llm-council: HTTP request timeout hardcoded at 120s — too short for slow NVIDIA NIM / large reasoning responses #90

Bug / Enhancement

skills/llm-council/scripts/council.js hardcodes the HTTP request timeout at 120000 ms (60s × 2) in the postJSON function signature (line 60):

function postJSON(urlStr, body, headers, timeoutMs = 120000) {

There's no way to extend this from the CLI. Long-running calls fail with council request timeout (or ETIMEDOUT at the TLS layer) and the user has no knob to widen it.

Symptoms

Reproduced on NVIDIA NIM free tier with reasoning models like z-ai/glm-5.2 and nvidia/nemotron-3-ultra-550b-a55b:free. Single-call latency routinely exceeds 120s on heavier queries:

ERROR: read ETIMEDOUT
    at TLSWrap.onStreamRead (node:internal/stream_base_commons:216:20)
    errno: -60, code: 'ETIMEDOUT', syscall: 'read'

The socket destroys and the council session errors out, even though the API call would have succeeded with a longer lived socket.

This especially hits:

• Long-context reasoning models (GLM-5.2 / Kimi / DeepSeek R1) on cold-start
• Free-tier upstream providers with high queue depth (NIM build.nvidia.com under load)
• Phase 3 chairman calls with very large ranking contexts

Proposed fix

Introduce a --timeout ms CLI flag (default 120000, preserves current behavior) sourced into RUN_OPTS.timeout_ms and used as the default for postJSON calls. Documented in usage().

Usage after fix

```bash
node $SKILL_ROOT/scripts/council.js run "" --models "..." --chairman "..." --timeout 300000
```

Upstream providers where this matters:

• NVIDIA NIM (https://integrate.api.nvidia.com/v1) — cold-start calls on 100K+ context can exceed 120s
• OpenRouter under high upstream queueing pressure
• Anthropic with Claude thinking mode on Phase 3 synthesis of long transcripts