The previous threading.Lock serialized every web_search call to work
around a thread pool starvation bug in ddgs < 9.12.1, where a process-
wide ClassVar ThreadPoolExecutor was shared across all DDGS instances.
Under concurrent callers the shared pool saturated, and combined with
DDG's per-IP rate limiting this presented as "blocked forever" (see
commit 310be71 which introduced the lock).

ddgs 9.12.1 (upstream PR deedy5/ddgs#445) replaced the shared pool with
a per-call, context-managed ThreadPoolExecutor. Each search now owns an
isolated, bounded executor that shuts down on exit, so inter-call pool
contention is gone.

- Pin ddgs>=9.12.1 so we can't slide back into the broken range
- Drop threading.Lock and thread import
- Introduce asyncio.Semaphore(max_concurrent=3) on the async side: lets
  up to 3 searches run in parallel via asyncio.to_thread while still
  capping fan-out to stay under DDG's per-IP rate limit
- max_concurrent is a constructor knob so the tuning can move without
  a code change when we learn more from production load

Adds 4 unit tests verifying the semaphore actually caps in-flight work,
parallel wall-clock beats serial, and the threading.Lock is gone.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>