chore(test): clarify concurrent mempool checks

[huklaa]

No description provided.

[osr21]

Verified against the code at f2100a6 — the new comment is accurate on every claim, more so than the TODO it replaces.

Both assertions check out in crates/test/checks/src/mempool.rs:

• "each RPC request is independently bounded by REQUEST_TIMEOUT" — REQUEST_TIMEOUT: Duration = Duration::from_secs(5) (L26) is applied via reqwest::Client::builder().timeout(REQUEST_TIMEOUT) (L39–41). reqwest's .timeout() is a per-request deadline, so yes, each txpool_status() call is independently bounded. ✅
• "shared reqwest client" — the client is built once in check_mempool and handed to every provider via connect_reqwest(client.clone(), …) (L46). reqwest::Client is Arc internally, so .clone() shares the same client and connection pool rather than making N clients. Accurate. ✅
• "Poll all providers concurrently" — join_all(futures).await (L68) drives all provider futures concurrently. ✅

Reframing TODO(parallel via tokio) → "concurrent" is the technically correct call. These futures are pure I/O (an awaited RPC each), so concurrency — many requests in flight on one task — is exactly what join_all gives and what this workload needs. tokio::spawn/multi-thread parallelism would add scheduling overhead and buy nothing here, since there's no CPU work to spread across cores. So the old TODO was pointing at the wrong tool; deleting it is right.

One soft note so the TODO's original intent isn't fully lost: the only real scaling concern for this pattern isn't parallelism, it's that join_all collects all futures up front; if the node/validator count ever grew very large, FuturesUnordered (or FuturesOrdered) would be the more memory/poll-efficient swap — not tokio tasks. At validator-set sizes this is a non-issue, so nothing to change now; just noting it in case someone later wonders where the "if the number of nodes is large" thought went.

Merge status (head f2100a6): mergeable=true, mergeable_state=blocked. Nothing red — check-runs are 1 success + 4 skipped, and the legacy combined status is the empty/no-status default, same as the other open docs/chore PRs in this batch. The block is maintainer-side (required review / branch protection), not anything in the PR.

Clean, correct clarification — LGTM.