Run independent arena games in parallel

[JuneQQQ]

Summary

Code-optimisation half of this maintenance cycle.

Independent arena games can now run in parallel via a thread pool. Real-LLM benchmarks spend almost all their wall-clock waiting on the provider (HTTP IO releases the GIL), so this scales close to linearly with worker count for the cases that actually matter. Aggregation is commutative — Arena._record under a single lock — so the resulting ArenaReport is bit-identical to the sequential run regardless of completion order.

Changes

• Arena.run gains max_workers: int = 1 (keyword-only). With >1, games are dispatched onto a ThreadPoolExecutor; recording is serialised under a lock; progress hook fires per game in completion order. Default behaviour unchanged.
• Leaderboard.run threads max_workers into the inner Arena.run calls.
• CLI: --workers N on deepwolf arena and deepwolf leaderboard.
• Docstring documents the thread-safety expectation: agents that share mutable state — notably MockProvider's RNG — should be instantiated per game by the factory in parallel mode. Factories that return fresh agents (the usual pattern) are safe automatically.

Why threads, not processes

For real-LLM use the bottleneck is network IO, which releases the GIL → threads scale linearly. Processes would require picklable factories (lambdas don't pickle) and would add startup overhead. The library's existing API is preserved exactly.

Checklist

• ruff / mypy / pytest (92 tests, 3 new) all pass
• Parallel run produces a bit-identical report to sequential (test_parallel_arena_matches_sequential_bit_for_bit)
• Default (max_workers=1) behaviour unchanged
• CHANGELOG updated

[JuneQQQ]

Code review (post-merge record).

• Determinism preserved: test_parallel_arena_matches_sequential_bit_for_bit verifies the parallel report equals the sequential one in every aggregate field (village_wins, werewolf_wins, total_days, role_stats, agent_stats). Aggregation is commutative and protected by a single lock, so completion order doesn't matter. ✅
• Backward compatible: max_workers=1 is the default and runs the original sequential path; test_max_workers_one_uses_the_sequential_path confirms parity. ✅
• Threads, not processes: correct call for the real-LLM use case where >99% of wall time is network IO (GIL released). Avoids the pickling pitfalls of ProcessPoolExecutor for closure factories. ✅
• Thread-safety expectation is documented in the Arena.run docstring — factories returning fresh agents per call are safe; shared mutable state (notably MockProvider's RNG) needs per-game instantiation. ✅
• Progress hook still fires once per game; the count is monotonic under the lock. ✅
• Leaderboard composes cleanly via max_workers pass-through; CLI exposes --workers N on both commands.

Solid optimisation. Merged via squash.