Parallelize live synthesis fan-out (~3x faster), determinism preserved

[anmolg1997]

Why

A live run is dominated by sequential LLM calls. The discovery agent loop is inherently serial (each turn feeds the next — can't parallelize without breaking the logic). But the synthesis fan-out was running ~10–13 independent calls (7 report sections + one per opportunity) one after another for no reason. They're I/O-bound API calls, so a thread pool gives real wall-clock parallelism.

Result: synthesis stage ~3× faster. Discovery loop untouched. Zero behavior change to output.

The design was vetted by an adversarial review pass before implementing; every load-bearing safety fix it surfaced is folded in.

What changed

fanout.py — run_synthesis_fanout submits the report sections + per-opportunity calls to a ThreadPoolExecutor and consumes futures in submission order (never as_completed). _merge / planning stay single-threaded on the main thread, so output is byte-identical regardless of thread scheduling. The one real dependency (pain-points pre-pass → opportunity seeds) is still a hard barrier in the caller.

• DISCOVERY_MAX_WORKERS env knob (default 4; =1 reverts to fully serial — the regression baseline).
• _safe_report / _safe_opp catch failures inside the worker so one bad section omits itself, never aborts the suite — and they catch only LLMRetryableError, not a plain LLMError, so a missing/invalid API key still aborts loudly instead of silently producing an empty report.

llm.py — LLMRetryableError subclass; _provider_error now classifies transient (429/529/connection → retryable) vs hard (auth/config → aborts). Locked double-checked lazy client init; max_retries=2 on the SDK client to absorb transient blips without wedging pool slots. _write_cache is atomic (temp in a sibling .cache.tmp/ on the same filesystem, then os.replace) so concurrent same-key writes can't tear a file or corrupt a --save-golden snapshot.

Rate-limit-adaptive omission — a section that can't be produced is omitted, warned loudly, and on --save-golden is a hard error (a polished snapshot is never silently short). Structural placeholder report specs (04's empty-instruction portfolio spec, whose content comes from the opportunity seeds) are excluded from omission tracking to avoid a false-positive warning.

Verified

• Golden byte-identical: o2c + p2p, workers=1 vs workers=4, and vs the committed baseline → zero behavior change, determinism fully preserved. (This was the non-negotiable gate.)
• 261 tests pass, 100% branch coverage, pyrefly clean. New tests: order-stable output at workers 1 vs 4, a real-concurrency proof (3-way barrier), omission reporting, placeholder exclusion, _provider_error classification, atomic concurrent cache writes, single locked client init.
• One real --fresh p2p live run at workers=4 completed end-to-end.

Residual risks (accept)

1. A sustained rate-limit (surviving max_retries=2) will omit a section rather than abort — now surfaced via the loud warning + the --save-golden hard-fail, so it's never silent. DISCOVERY_MAX_WORKERS=1 avoids bursting the API if a tier is tight.
2. Live recording isn't bit-reproducible (model re-sampling) — pre-existing, unchanged; this is why the determinism proof uses --golden replay, not fresh-run bytes.

Out of scope

The discovery agent loop (inherently sequential).