fix(synthesis): raise reduce output cap so the breadth brief finishes

[bryanmatthewsimonson]

Problem

Re-running corpus synthesis on the COVID-origin case (~125 members) fails with "Synthesis failed: The synthesis hit its output limit before finishing." — runCorpusReducePass seeing stop_reason: 'max_tokens' against MAX_REDUCE_OUTPUT_TOKENS = 16384.

Two compounding causes:

1. The corpus-v3 breadth nudge (PR feat(synthesis): representative claim digest + map/reduce version split #193 — "list EVERY holder", "enumerate ALL cruxes") makes the reduce emit a whole-corpus brief that legitimately runs ~18–25k output tokens for a case this size (every position's holders as full 64-hex hashes, all cruxes, load-bearing, the proposal queue).
2. The reduce omits the thinking param, so on Sonnet 5 adaptive thinking is on by default and those thinking tokens share the same max_tokens budget — Sonnet had less room for the brief than the earlier (pre-nudge) Opus run that fit in 16384.

Fix (surgical — no prompt change, no breadth regression)

• MAX_REDUCE_OUTPUT_TOKENS 16384 → 32768 — far under every current model's 128k output ceiling; gives the breadth brief room plus headroom for Sonnet's adaptive-thinking overhead.
• CORPUS_REDUCE_TIMEOUT_MS 300000 → 420000 — the now-larger brief takes longer to generate (~22k tokens × ~55 tok/s on the slower Opus tier ≈ 400s); a longer ceiling avoids trading a token-cap failure for an abort. The reduce is the one long single fetch in the corpus flow; its pending sendResponse keeps the MV3 service worker alive.

Deliberately NOT a prompt/tool/digest change → no MAP_PROMPT_VERSION / CORPUS_PROMPT_VERSION bump → the ~100 cached map extracts and brief-staleness keys are untouched (the version-pinning tests stay green, and re-running only pays for the reduce, not a re-map).

Verification

• npm run build clean
• npm test — 1976 pass / 0 fail
• npm run lint — 0 errors (exit 0)

🤖 Generated with Claude Code