Intermittent connection pool exhaustion in Hardhat Network under concurrent JSON‑RPC load

Goal: Identify the concurrency level at which Hardhat Network’s built‑in connection pool begins to reject or delay JSON‑RPC requests, producing intermittent timeouts or 'connection pool exhausted' messages.

Constraints: The pool size is not documented or configurable in hardhat.config.js, and its effective limit changes depending on whether the network is forked, how many provider instances are active, and whether the Hardhat network is reset between test runs. This variability makes the exhaustion point unpredictable and complicates reproducing the symptom in a test suite.

Questions: What is the default connection pool size used by Hardhat Network? Does enabling forking alter the effective pool size or consumption rate? Is there a supported way to observe pool utilization or saturation without relying on undocumented internal APIs?