Fusion runner should enforce bounded panel/output resource limits

[bearmug]

Summary

Fusion should keep resource usage bounded, but the original OOM framing was too broad. Current packages/fusion/src/runner.ts runs one recipe at a time and parallelizes only that recipe's analysis_models; packages/fusion/src/recipe.ts already caps panel width at MAX_PANEL_MODELS = 8 and caps token/time parameters.

The useful remaining work is to define explicit guardrails for panel response size, trace size, synthesis/judge input size, and diagnostics when Fusion approaches those limits.

Current mainline behavior

• runFusionCompletion() runs panel calls with Promise.all(recipe.analysis_models.map(...)) for one recipe.
• Recipe validation rejects more than 8 panel models.
• max_completion_tokens, timeout_ms, and per_model_timeout_ms are capped by validation.
• Full raw panel/judge/synthesis traces are written to local run trace files.
• Judge and synthesis contexts currently include raw panel responses, so very large outputs can be re-forwarded and persisted.

So this is not currently a proven "100 recipes run concurrently and OOM" bug.

Remaining concern

Even with panel width capped, Fusion can still accumulate large strings in memory and trace files when panel models return very large responses, especially because the same panel content may be:

1. kept in responses,
2. forwarded to the judge,
3. forwarded again to synthesis,
4. written to the trace file.

This is a bounded-resource hardening issue, not a demonstrated immediate OOM crash.

Proposed work

Add conservative limits and diagnostics around Fusion text payloads:

1. Define max panel response chars/bytes per model.
2. Define max total panel response chars/bytes per run.
3. Truncate or summarize oversized panel responses before judge/synthesis forwarding, while preserving a trace note that truncation occurred.
4. Bound trace write size or explicitly mark/truncate oversized raw fields.
5. Include resource-limit metadata in FusionRunResult / trace, e.g. truncated models, original sizes, effective sizes.
6. Keep existing panel-count and timeout/token validation intact.

Non-goals

• Do not add a generic queue system.
• Do not add subagents or orchestration changes.
• Do not claim recipe-level unbounded concurrency where current code only runs one recipe.
• Do not remove useful traceability; truncate with metadata rather than silently dropping content.

Acceptance

• Fusion has documented per-response and per-run text size limits.
• Oversized panel output cannot be blindly re-forwarded to judge/synthesis without truncation/metadata.
• Trace files remain bounded or clearly truncate oversized fields.
• Tests cover oversized panel responses and verify judge/synthesis receive bounded content.
• Issue no longer claims a proven high-severity OOM path from unlimited recipe concurrency.

[bearmug]

Additional validated scope for this open resource-limit issue, from the mainline audit at aa595438650cfbaa6db310792929c6219cc003b2:

• recipe validation accepts omitted or zero timeout_ms and max_completion_tokens; zero becomes no deadline;
• timeout is applied separately to panel, judge, and synthesis rather than as one top-level run deadline;
• context-overflow retry permits up to 2N + judge + synthesis calls, while current README budgeting says N + judge + synthesis;
• effective total deadline/call ceiling is not exposed in status/trace.

Suggested acceptance additions for #173:

• require positive finite values or install finite defaults;
• enforce one top-level Fusion deadline across retries, panel, judge, and synthesis;
• reject zero completion tokens/timeouts;
• expose effective total call/time/token budgets in status/trace;
• test omitted/zero values and context-overflow retry against the top-level budget.