Follow-ups to PR #5697 (TracePoint :class hot-load hook):

- enqueue_hot_load now bails out early when @hot_load_tracepoint has been
  cleared. TracePoint#disable does not wait for in-flight callbacks, so a
  :class event firing concurrently with stop_upload could reach
  enqueue_hot_load after the hook had been torn down and re-arm the
  scheduler — contradicting stop_upload's contract. The buffer push is
  harmless because the next start_upload runs extract_all (since
  @initial_extraction_done was reset), which clears the buffer first. A new
  spec exercises this race directly by calling enqueue_hot_load after
  stop_upload.

- Components#after_fork now has a dedicated spec covering the
  symbol_database&.after_fork! wiring added in #5697 — both the dispatch
  path and the nil-safety case.

- Three sleeps in component_spec.rb replaced with deterministic waits:
  - "clears scheduler thread reference and pending schedule": @scheduler_thread
    is assigned synchronously inside start_upload's mutex via
    ensure_scheduler_thread, so the sleep was never needed.
  - "leaves a child Component able to start_upload normally after fork-state
    reset": replaced sleep with wait_for_idle.
  - "stop_upload prevents a post-stop class definition from triggering
    extraction": removed sleep — the @scheduled_at nil check is the
    structural proof (only enqueue_hot_load sets it after stop_upload, and
    enqueue_hot_load only runs if the TracePoint fired).

- EXTRACT_DEBOUNCE_INTERVAL RBS type changed from Integer to ::Numeric.
  Production value is the Integer 5, but the constant participates in
  arithmetic with Float clock values and is stubbed to 0.05 in tests.

Verified with:
- bundle exec rspec spec/datadog/symbol_database/component_spec.rb
  (50 examples, 0 failures)
- bundle exec rspec spec/datadog/core/configuration/components_spec.rb
  (passes, including the two new after_fork examples)
- bundle exec steep check lib/datadog/symbol_database/component.rb (clean)

Co-Authored-By: Claude <[email protected]>

The :class TracePoint fires inside the customer's `class Foo; ... end`
body. An exception escaping the callback propagates into the class
definition itself — verified empirically: a `raise` inside a :class
TracePoint backtraces through `<class:CustomerClass>` and surfaces at
the customer's `class` keyword, breaking their class load.

The earlier MODULE_SINGLETON_CLASS_PRED dispatch closed one specific
raise source (user-overridden `singleton_class?` with an incompatible
signature). This commit closes the general case with a rescue around
the callback body, matching the sibling pattern in `start_upload`,
`scheduler_loop`, and `extract_and_upload`: log at debug, report via
telemetry, allow the customer's class load to proceed.

New spec rigs `enqueue_hot_load` to raise, then defines a class —
asserts the class body does NOT raise, and that the debug log fires
with the failure details.

Co-Authored-By: Claude <[email protected]>

The hot-load end-to-end test in remote_config_integration_spec.rb failed
on Ruby 2.6 batch 0 with seed 16392 — two test failures cascading:

  1) hot-load end-to-end / uploads a class defined after the initial
     upload completes:
     `expect(initial_form_count).to be >= 1` got 0
  2) extract_all module with methods AND nested class in same file
     places child class under parent module in the same FILE scope:
     `expect(file_scope).not_to be_nil`

Root cause of (1): the test called `wait_for_idle(timeout: 5)` without
checking the return value. On Ruby 2.6 with heavy monkey-patching from
AppSec specs running in seed-16392 order before this test, extract_all
exceeded 5s — the extractor.rb comment at collect_extractable_modules
specifically calls this out:

  > on Ruby 2.6 specifically, Module#name on unnamed singleton classes
  > with long ancestor chains (e.g. through monkey-patches prepended
  > into Kernel, common in dd-trace-rb test processes) is O(ancestors)
  > — measured ~20ms per call

wait_for_idle silently returned false on timeout, captured_forms was
still empty, the assertion failed at line 235. The test body's
`component.shutdown!` at the end was never reached → scheduler thread
leaked → continued running extract_all → eventually crashed with
ExpiredTestDoubleError on the inherited InstanceDouble logger, and
concurrently raced ObjectSpace iteration with extractor_spec's
extract_all in the next spec, causing failure (2).

Fix:
- Bump both wait_for_idle calls to 30s, matching the other e2e test in
  the same file (line 84).
- Add `expect(...).to be true` to the first wait_for_idle, matching the
  pattern already used at the second wait_for_idle in the same test.
- Wrap the test body in begin/ensure so component.shutdown! always runs
  — a mid-test failure must not leak the scheduler thread and pollute
  subsequent specs in the same rspec process.

Verified on Ruby 2.6.10 locally:
  bundle exec rspec spec/datadog/symbol_database/component_spec.rb \
    spec/datadog/symbol_database/remote_config_integration_spec.rb \
    spec/datadog/symbol_database/extractor_spec.rb
  → 181 examples, 0 failures

Also verified on Ruby 3.2.3: 223 examples, 0 failures across the
related spec files.

Note: this is a fix to a test added in merged PR #5697. It's pulled
into this PR (#5871) because the bug surfaces from this PR's batch
composition (4 new tests shift the random seed). Independent of
#5871's other follow-up fixes.

Co-Authored-By: Claude <[email protected]>