ThreadPool concurrency refactoring (#2220)

[MitchLewis930]

PR_053

---

Note

Medium Risk
Touches core thread-pool synchronization and shutdown/trim behavior, which can impact request handling and termination under load; changes are localized but concurrency-sensitive.

Overview
Refactors Puma::ThreadPool’s concurrency control by introducing with_mutex (allowing safe nested locking) and switching key operations (backlog, enqueue, capacity waiting, trim/reap, shutdown) to use it.

Adjusts worker lifecycle semantics: startup now waits for worker readiness when creating the minimum threads; trim only requests exits when there are truly free threads; and shutdown drives worker exits by setting @trim_requested = @spawned and broadcasting, with workers decrementing counters and exiting immediately when trimming.

Reworks test_thread_pool.rb to avoid timing-based races by using a MutexPool test helper that batches work and waits for completion, adds a dedicated thread-name assertion, and adds a new startup waiting assertion. History.md notes the ThreadPool concurrency fixes/refactor.

^{Written by Cursor Bugbot for commit b16d8cb. This will update automatically on new commits. Configure here.}