test: migrate timer-based tests to testing/synctest

[kakkoyun]

What does this PR do?

Migrates timer-dependent and polling-loop tests to use Go 1.25's
testing/synctest fake-clock
bubbles, replacing real wall-clock sleeps and assert.Eventually
polling with deterministic, instant-in-fake-time equivalents.

The migration is structured in four phases:

Phase 0 — extend internal/synctest wrapper with a Wait()
re-export.

Phase 1 — pure timer tests (1 sleep replaced per test):

• internal/log/log_test.go — rate-limiter expiry
• ddtrace/tracer/span_test.go — duration measurement + polling
• ddtrace/tracer/stats_test.go — concentrator flush
• ddtrace/tracer/writer_test.go — concurrent flush

Phase 2 — assert.Eventually + injectable-time patterns:

• ddtrace/tracer/abandonedspans_test.go — replace 10
  assert.Eventually calls and defer setTestTime()() overrides; span
  start times are now relative to time.Now() inside each bubble.
• internal/telemetry/client_test.go — wrap TestClientFlush
  table-driven loop in synctest.Test; fix heartbeat case with a 1 ns
  sleep; remove runtime.Gosched() (no-op inside bubbles); use defer c.Close() instead of t.Cleanup so the ticker goroutine stops before
  the bubble exits.

Phase 3 — polling loops:

• ddtrace/tracer/tracer_test.go: migrate TestTracerAtomicFlush and
  TestWorker; replace a time.After(2s*timeMultiplicator) +
  time.Sleep(10ms) polling loop with synctest.Wait() + direct
  assertion.

Phase 4 — cleanup: remove setTestTime(), which overrode the
package-level now var for deterministic span-age strings. The
synctest fake clock makes this override redundant.

Motivation

Timer-based tests that use time.Sleep or assert.Eventually are
inherently racy and slow. They either rely on wall-clock timing (fragile
in CI, slow on loaded machines) or use inflated timeouts that make the
suite unnecessarily slow. testing/synctest provides a fake clock where
time.Sleep(1 * time.Second) is instant and deterministic, eliminating
the root cause rather than working around it with time multipliers.

Reviewer's Checklist

• Changed code has unit tests for its functionality at or near 100% coverage.
• System-Tests covering this feature have been added and enabled with the va.b.c-dev version tag.
• There is a benchmark for any new code, or changes to existing code.
• If this interacts with the agent in a new way, a system test has been added.
• New code is free of linting errors. You can check this by running make lint locally.
• New code doesn't break existing tests. You can check this by running make test locally.
• Add an appropriate team label so this PR gets put in the right place for the release notes.
• All generated files are up to date. You can check this by running make generate locally.
• Non-trivial go.mod changes, e.g. adding new modules, are reviewed by @DataDog/dd-trace-go-guild. Make sure all nested modules are up to date by running make fix-modules locally.