fix: validate function tool concurrency type

[hsusul]

Summary

• reject boolean and non-integer max_function_tool_concurrency values when constructing ToolExecutionConfig
• preserve the existing behavior for None, positive integers, and integers below one
• prevent fractional values from being interpreted as an unintended ceiling-like task count and True from acting as a limit of one

Test plan

• Added tests for the behavior being changed
• Ran .agents/skills/code-change-verification/scripts/run.sh
• Ran all relevant verification commands
• Ran /review

Focused validation:

• uv run pytest tests/test_run_config.py -q (44 passed)
• uv run pytest tests/test_run_step_execution.py -q -k function_tool_concurrency (3 passed, 105 deselected)
• independent review tests (4 passed, 40 deselected)
• mandatory verification wrapper (format, lint, typecheck, and tests all passed)

The separate parallel make tests run completed with 8954 passed, 28 skipped, 38 failed; all failures require local socket binding, multiprocessing, or native macOS sandbox execution, which this environment blocks. None touched the changed configuration tests or execution path.

Issue number

N/A

Checks

• I added tests for the behavior being changed
• I ran the repository verification script
• All relevant validation passes
• I reviewed the final diff

[seratch]

Thanks for the contribution. max_function_tool_concurrency is publicly typed and documented as int | None; a fractional value already violates that contract, and the current behavior for True requires relying on Python's bool subclassing plus an intentionally unusual runtime value. The tests establish constructibility, but not a supported producer, ordinary configuration path, or meaningful user impact.

I am going to close this PR because the additional runtime type contract is not justified by the demonstrated need. We can revisit fail-fast validation if a supported untyped configuration boundary is shown to produce these values in ordinary use.