[Feature]: Opt-in inline council synthesis to avoid relaying councillor responses through the orchestrator context twice

Description

Current flow (v2.2.4+, flatten dispatch from #816): the orchestrator fans out councillors via task() at depth 1, each response returns to the orchestrator context as a task result, and Council Mode step 4 (src/agents/index.ts) then instructs the orchestrator to re-embed ALL responses verbatim into the council agent's prompt for synthesis.

Cost: councillor responses cross the orchestrator's context twice. The second copy is emitted as orchestrator OUTPUT tokens — typically the most expensive model in the stack, while councillors are often budget/free models. With a 5-seat preset and unbounded response length, the full payload is duplicated at the worst available rate.

The first transit is inherent to the task() model (results return to the caller). The second is protocol text and could be made optional.

Proposal: an opt-in config, e.g. council.synthesis_mode: "agent" | "inline" (default "agent" = current behavior). When "inline", the injected Council Mode block replaces step 4 with "synthesize the collected responses yourself, preserving per-councillor attribution and the consensus/disagreement summary format". This is a pure conditional in the prompt-block injection — no new session machinery, no revival of CouncilManager-style plumbing.

Tradeoff (informed choice for the user): inline synthesis gives up the dedicated synthesis model (temperature 0.1) and the enforced report contract, in exchange for removing the second transit and one agent session per council run.

Today's partial workaround: per-seat response caps are already possible via each councillor's prompt field, but the relay itself has no switch.

Extra context

Related: #407 motivated the flatten; #816 introduced the current protocol (no token/context cost discussion in that PR); #868 / #885 / #1104 are the adjacent context/token-budget work this would align with.