Your debug log shows your Pi-hole's Conditional Forwarding is disabled, and your router's DHCP server is distributing two local IPs as DNS servers.
This would rule out the most common causes for a partial DNS loop, leaving us with excessive requests or unavailable upstreams.
Likely, unblocking that domain would not affect your observation - it could even make your observation worse.
This observation may be a symptom rather than the cause.
3.000 requests are not enough to overwhelm pihole-FTL's/dnsmasq's connection pool, especially if those have been blocked. Pi-hole could handle those requests using a single connection.
Assuming that requests arrive with a 1 ms network latency, Pi-hole would be blocking them instantly within a few nanoseconds, i.e. the connection would be free long before the next request would arrive.
Now, if the request would be forwarded, then Pi-hole's upstream server's latency would determine how quick a thread could complete.
Assuming a 100 ms upstream latency, that would mean Pi-hole could free the first connection when the 101st request arrives, employing 100 connections - still not enough to exhaust the connection pool.
Furthermore, since requests are for the same domain, Pi-hole may collate those requests and not forward duplicates upstream before the first reply is received, and it would then serve replies from the cache, which again would be instantly.
But if your upstream would be unresponsive or unreachable at times, Pi-hole would have to wait until that upstream answers, or until time-out (usually, a few seconds).
In that scenario, any 150 requests would be enough to use up all connections, and Pi-hole would have to turn down any DNS request arriving after that, resulting in the Maximum concurrent warning.
Thus, it seems most likely that your upstream is somehow causing your issue.
As you are using unbound, and unbound in recursive mode would be talking to authoritative DNS servers directly, you should probably verify if only those specific domain requests would not be answered by unbound in time, which in turn could suggest that the respective authoritative DNS servers would be unresponsive.
If it'd turn out that all of unbound's requests would time out, that could suggest an unreliable internet connection, or perhaps an incorrect time on your unbound machine.
You should investigate Pi-hole's Query Log for unbound's replies at the time of a Maximum concurrent warning.
