fix(pipeline): scale both tool budgets to the model, not the global config

[github-actions]

The tool loop read p.ctxCfg raw while the context assembler scales to the
target model (effCfg.WindowSize = modelCfg.ContextWindow). Two consequences,
both found investigating a user losing page content mid-turn:

• toolTokenBudget came from the GLOBAL context.window_size (65536) regardless
  of which model ran the turn. On a 32k chat backend the loop accumulated up to
  ~10.7k tokens of tool results while the assembler packed for 32k, so the loop
  over-filled relative to the real slot.
• perResultCap was a flat max_tool_result_tokens forever. Moving to a
  bigger-context backend did nothing for the biggest symptom: CapToolResult
  keeps head+tail and drops the MIDDLE, so any wiki page over the cap comes
  back gutted. Reading ~10k-char transcript pages, that silently loses the body
  on every read.

Now both derive from a model-scaled copy. The configured per-result value is
treated as the floor at the 64k window it was tuned against and grows linearly
above that, so a larger backend genuinely buys larger reads. Grow-only: a
smaller window never shrinks the operator's configured cap.

Measured effect (ratio 0.18, reservation 4096, cap 2500):
32k -> 2500 tok cap, 5160 tok/turn (~2.1 full 10k-char pages)
64k -> 2500 tok cap, 11059 tok/turn (~4.4)
128k -> 5000 tok cap, 22855 tok/turn (~4.6)

Note the per-result cap is unchanged at or below 64k by design — raising it
there is an operator decision, and max_tool_result_tokens was separately raised
2500 -> 4000 in gateway.toml so today's ~10k-char pages fit whole.

---

Opened automatically after the tiers check passed on 7fe3832c.

The check is attached to this branch head, so this is mergeable now.