Make max_tool_steps configurable, and actually wire it up

[justinmclean]

What this changes

The tool-calling loop in openai_agent.py ran on the hardcoded MAX_TOOL_STEPS = 20. That is enough for a report-writing subtask and not for one that has to extract, compile and then summarise: such an item hit the cap repeatedly, each time doing most of the work and returning no answer at all.

max_tool_steps is now a scalar key at [harness], inside a stage table and inside a profile, resolved like every other. Two details that made the first cut of this silently ineffective:

• _build() has to pass max_tool_steps into the top-level HarnessConfig. The key already passed the _HARNESS_SCALAR_KEYS check, so omitting it there raised no error; the field stayed None and the loop fell back to 20, producing runs that reported a cap of 20 while the file said 35 -- exactly the silent misconfiguration that key check exists to prevent.

• _finalise() has to coerce it to int. _scalar() stringifies every value during layering, so a per-stage max_tool_steps arrived as "35" and range("35") raises TypeError. max_tokens was already coerced; the loop now covers both integer keys.

The step-cap error message also names the setting and the alternative (split the subtask), since the number in it is now configurable.

Checklist

• One work item only — nothing unrelated bundled in
• make check is green locally
• Tests cover the change, including refusal paths (the negative cases
  are the product)
• No test, acceptance criterion, or check was weakened to get green
• No changes under specs/ (spec changes go through an issue first)
• Docs updated where behaviour changed (README / USAGE.md)
• Commit subjects are imperative; Generated-by: trailer present if an
  agent wrote the change