…ans (APMS-19944) (#4030)

* fix(curl): enforce DD_TRACE_SPANS_LIMIT for curl_multi_exec parent spans (APMS-19944)

The curl_multi_exec integration opens its parent span via the user-facing
DDTrace\start_span(), which intentionally bypasses DD_TRACE_SPANS_LIMIT
(see #3691). Distributed-header injection then flags that span NOT_DROPPABLE,
so the post-hook's try_drop_span() can never reclaim it. In long-running CLI
workloads that repeatedly call curl_multi_exec (e.g. AWS SDK SQS batches),
one un-droppable span accumulates per call, growing memory 1:1 with calls
until OOM.

Skip creating the parent span when the tracer is already limited. Distributed
tracing headers are still injected by the C handler against the active span,
so propagation is preserved, and the child request spans are already limited.

Fixes: APMS-19944

* test(curl): drop flaky is_limited assertion from span-limit test

dd_trace_tracer_is_limited() reflects the open+closed span counters at the
moment of the call, which depends on end-of-run flush/cleanup timing and
varies across CI environments and PHP versions (7.3/7.4/8.2-ASAN all reported
bool(false) at script end). The span-count assertion (BOUNDED) is the real
regression guard: with the fix the retained curl_multi_exec spans stay capped
near DD_TRACE_SPANS_LIMIT, without it they scale 1:1 with iterations. Bump to
100 iterations for a clearer margin and drop the fragile check.

* test(curl): remove comments from span-limit test

* fix(curl): check span limit at top of curl_multi_exec hook

Address review: move the ddtrace_tracer_is_limited() guard to the start of
the begin hook so the limited path returns immediately, skipping the args
lookup and ObjectKVStore reuse check. Spans for a multi-op are only created
on the first curl_multi_exec call, so a new handle has nothing to reuse when
limited; the boundary case (parent created just before the limit) is still
finalized by CurlSpanInfo::__destruct().