fix(tools): bound the forced reasoning steps by their own output cap

[walcz-de]

With WithForceReasoning, the forced reasoning calls before the tool pick and before parameter generation carry no output cap of their own. A model that never closes the reasoning argument therefore runs to the client's global cap (16384 by default), and the length retry then doubles it. With gemma4-26b-a4b behind LocalAI, one such call streamed ~13k tool-call deltas for ~8 minutes and the turn never answered.

This PR adds WithReasoningMaxTokens and sends it as max_tokens on both reasoning calls, so the request-level cap wins over the client default (see SetMaxTokens):

• default DefaultReasoningMaxTokens = 2048
• 0 uses the default
• a negative value restores the previous uncapped behaviour

A finish_reason=length on a capped step is final, with no length retry:

• the tool pick continues without the reasoning;
• the parameter step takes its existing fallback;
• a complete call that is cut at the cap, and reasoning that finishes normally, are used as before.

All other decisions are unchanged, and the option is forwarded to plan sub-executions.

Tests:

• Ginkgo specs cover endless tool-pick reasoning, endless parameter reasoning, a short-reasoning counter-check and the option semantics.
• Internal tests cover the non-streaming path and the unchanged length retry without a cap.
• Without the fix, 3 of the specs and the non-streaming cap test fail. make test passes (88/88).

🤖 Generated with Claude Code

https://claude.ai/code/session_01Y8ngj32vPUcLs3QKgTYCxy