ci(tests): cap the pytest matrix at 15 concurrent jobs

[justinmclean]

Summary

The pytest matrix in tests.yml has one job per workspace member and no max-parallel. On a push to main, or a PR that touches pyproject.toml or uv.lock, it starts about 46 jobs at once. The last push run had 48 jobs in total. The ASF Infra GitHub Actions policy caps a workflow at 20 concurrent jobs and recommends 15: https://infra.apache.org/github-actions-policy.html. This sets max-parallel: 15. The other workflows already meet the policy: no pull_request_target, every external action is pinned to a SHA, and nothing pushes to main.

Type of change

• Skill change (.claude/skills/<name>/) — eval fixtures updated below
• Tool / bridge contract (tools/<system>/*.md)
• Python package (tools/*/ with pyproject.toml)
• Groovy reference impl
• Cross-cutting (RFC, AGENTS.md, sandbox, privacy-LLM)
• Documentation (docs/, README.md, CONTRIBUTING.md)
• Project template (projects/_template/)
• CI / dev loop (prek, workflows, validators)
• Other:

Test plan

• [X ] prek run --all-files passes
• For Python packages touched: uv run pytest / ruff check / mypy passes
• For Groovy bridges touched: command-line invocation tested end-to-end
• For skill changes: eval suite passes for the affected skill
  (PYTHONPATH=tools/skill-evals/src python3 -m skill_evals.runner tools/skill-evals/evals/<skill>/)
• For skill behaviour changes: a new or updated eval fixture is included in this PR
  (a regression test for the bug fixed / the behaviour added — see CONTRIBUTING.md)
• Other:

[potiuk]

Just one small comment here: vast majority of the PRs will only run one of those :) ... Because they are executed based on which project has changed ..

But yeah - capping for full run is a good idea :)