DI: do not advertise LIVE_DEBUGGING on unsupported runtimes

[p-datadog]

What does this PR do?

Resolves the long-standing TODO in Datadog::DI::Remote.products — the tracer no longer advertises the LIVE_DEBUGGING remote-config product (or the implicit-enablement capability, bit 38) on runtimes where Dynamic Instrumentation can never run (JRuby, Ruby 2.5).

The DI registration block in Core::Remote::Client::Capabilities#register now also requires Datadog::DI.supported_runtime?:

if settings.respond_to?(:dynamic_instrumentation) &&
    !Datadog::DI::Remote.explicitly_disabled?(settings) &&
    Datadog::DI.supported_runtime?
  register_capabilities(Datadog::DI::Remote.capabilities)
  register_products(Datadog::DI::Remote.products)
  register_receivers(Datadog::DI::Remote.receivers(@telemetry))
end

Datadog::DI.supported_runtime? is the platform-support subset of DI.unsupported_reason — RUBY_ENGINE == 'ruby' && Datadog::RubyVersion.is?('>= 2.6'). It deliberately excludes the C-extension and configuration checks so it can be evaluated without settings and without depending on a build artifact (the compiled extension is always present in shipped gems on supported runtimes; gating on it would couple registration to the build and break spec:main where the extension is not compiled).

Motivation:

This is a follow-up to #5525 (implicit DI enablement via remote configuration). With always-build, the DI remote-config block registers LIVE_DEBUGGING and bit 38 whenever DI is not explicitly disabled — including for default-off customers on JRuby and Ruby 2.5. On those runtimes Component.build returns nil and DI::Remote.receivers drops every change, so the backend would send probe configs and enable signals the tracer silently discards, and the service could appear DI-capable in the Live Debugger UI when it is not.

Change log entry

None. Refines the unreleased implicit-enablement feature (#5525); its customer-facing changelog entry lives in that PR.

Additional Notes:

Stacked on #5525 (base branch enablement) because the fix builds on that PR's always-build structure (CAPABILITIES, explicitly_disabled?, the gated registration block). Rebase onto master and retarget the base once #5525 merges.

Draft pending #5525.

How to test the change?

bundle exec rspec spec/datadog/di_spec.rb \
  spec/datadog/core/remote/client/capabilities_spec.rb \
  spec/datadog/di/remote_spec.rb

New coverage:

• capabilities_spec.rb — an "unsupported runtime (JRuby or Ruby 2.5)" context asserting DI capabilities, product, and receivers are NOT registered even when DI is enabled; existing DI-registration contexts stub supported_runtime? to remain deterministic across the Ruby matrix.
• di_spec.rb — .supported_runtime? across MRI 2.6+ (true), JRuby (false), and MRI < 2.6 (false).

bundle exec rake standard typecheck clean.

[pr-commenter]

Benchmarks

Benchmark execution time: 2026-06-25 16:35:20

Comparing candidate commit 30b3186 in PR branch di-skip-rc-on-unsupported-runtime with baseline commit 72bfce8 in branch enablement.

Found 0 performance improvements and 0 performance regressions! Performance is the same for 48 metrics, 1 unstable metrics.

Explanation

This is an A/B test comparing a candidate commit's performance against that of a baseline commit. Performance changes are noted in the tables below as:

• 🟩 = significantly better candidate vs. baseline
• 🟥 = significantly worse candidate vs. baseline

We compute a confidence interval (CI) over the relative difference of means between metrics from the candidate and baseline commits, considering the baseline as the reference.

If the CI is entirely outside the configured SIGNIFICANT_IMPACT_THRESHOLD (or the deprecated UNCONFIDENCE_THRESHOLD), the change is considered significant.

Feel free to reach out to #apm-benchmarking-platform on Slack if you have any questions.

More details about the CI and significant changes

You can imagine this CI as a range of values that is likely to contain the true difference of means between the candidate and baseline commits.

CIs of the difference of means are often centered around 0%, because often changes are not that big:

---------------------------------(------|---^--------)-------------------------------->
                              -0.6%    0%  0.3%     +1.2%
                                 |          |        |
         lower bound of the CI --'          |        |
sample mean (center of the CI) -------------'        |
         upper bound of the CI ----------------------'

As described above, a change is considered significant if the CI is entirely outside the configured SIGNIFICANT_IMPACT_THRESHOLD (or the deprecated UNCONFIDENCE_THRESHOLD).

For instance, for an execution time metric, this confidence interval indicates a significantly worse performance:

----------------------------------------|---------|---(---------^---------)---------->
                                       0%        1%  1.3%      2.2%      3.1%
                                                  |   |         |         |
       significant impact threshold --------------'   |         |         |
                      lower bound of CI --------------'         |         |
       sample mean (center of the CI) --------------------------'         |
                      upper bound of CI ----------------------------------'