fix(summarize): make its per-call budget configurable, and count the calls it abandons

[itay-nakash]

Why

#64 gave extract_llm a configurable per-call budget and counters for the calls it
abandons. summarize was left on a hardcoded summarizeCallTimeout = 150 * time.Second
— and the 10x asymmetry with the old 15s ceiling hid the fact that it has the same
failure mode: on a loaded self-hosted backend the deadline can expire before the model
answers, and today the operator has neither a knob nor a counter to see it happen.

Two terms make summarize's budget the harder of the two to size, and they add:

• Queue wait — what a loaded server actually charges: measured p50 17.2s / p95 78.8s
  under KV-cache pressure, before the model starts work at all.
• Its own prefill, which is large by construction. Measured over one 50-task SWE-bench
  arm: 78,155,276 input tokens across 1,372 calls, i.e. ~57k prompt tokens per call,
  because it summarizes the whole middle of the transcript.

The same arm spent 26,890,609 ms on those calls — a 19.6s mean on an idle server. So
150s looked like 7.6x headroom while only measuring the third of those three terms.

What

• CONTEXT_GURU_SUMMARIZE_TIMEOUT (Go duration; bare integers are seconds) sets the
  budget, defaulting to 300s. Deliberately separate from CONTEXT_GURU_LLM_TIMEOUT: the
  two components send requests differing in size by ~20x, so one ceiling is either
  generous for one or tight for the other.
• summarize_timeouts / summarize_errors / summarize_call_timeout_ms at /stats,
  merged by the host with the same layering as the LLM* and Frozen* counters, and
  registered in the /stats golden contract. Separate from llm_timeouts for the same
  reason as the budget: a summarize-only pipeline reports llm_timeouts 0 however badly
  its own deadline is being hit.
• Timeout distinguished from transport error. summarize's fail path is louder than
  extract_llm's — it returns the error and the pipeline reverts the component, which
  surfaces as a per-component reverted count — but reverted cannot say why, and the
  two causes call for opposite responses: a blown deadline means the budget is too small
  for this load (savings are an undercount), a model error means the compaction route is
  broken (the arm is not measuring summarization at all).
• The retry loop stops once the shared deadline has expired. The ctx is built by the
  caller, outside the loop, so all three attempts share one deadline; past it each retry
  failed instantly and only obscured the cause. This also makes explicit that the worst
  case is one budget, not three.
• Env parsing extracted to resolveTimeoutEnv and shared with extract_llm rather than
  duplicated — a value accepted by one component and silently ignored by the other would
  be invisible in a run and would look like the component not firing.

Fail-open behaviour is unchanged throughout: a summarize that cannot summarize must leave
the request valid. What changes is that a loaded server gets time to answer, and that
giving up is now countable.

Testing

make test (-race) and make lint green; the suite also passes with -tags cg_skeleton.

New summarize_timeout_test.go:

• a slow model that always exhausts the deadline is counted as a timeout, not an error,
  and the model is asserted to have actually been called (otherwise a component that
  merely declined would make the assertion vacuous — the same trap called out in the
  extract_llm timeout test);
• the message list is left intact on the error path. summarize is the one component that
  changes the message count, so a partial rebuild would hand the caller a transcript with
  no summary in it;
• a table test for the shared parser: bare integers as seconds, Go durations, whitespace,
  and fallback on zero / negative / garbage.

Note on the default

300s is a ceiling, not a target — on an idle server nothing changes, because the call
still returns in ~20s. It is sized so that queue wait plus a ~57k-token prefill still fit.
The cost of a large ceiling lands on the agent (the call is on the request's hot path), so
the counters matter as much as the number: past some load level the honest answer stops
being "raise the budget" and becomes "this concurrency cannot serve compaction and the
agent at once".