fix(ruby): observability plugin compatibility — require server-sdk >= 8.11.0 and fix Rails Railtie load order

[ccschmitz-launchdarkly]

Summary

Two compatibility fixes for the Ruby observability plugin, both surfaced by a customer trying to get launchdarkly-observability working in a Rails app (Slack thread).

1. Require launchdarkly-server-sdk >= 8.11.0

The plugin includes LaunchDarkly::Interfaces::Plugins::Plugin at load time, but that interface was only added in server-sdk 8.11.0 ("Add experimental plugin support"). The gemspec allowed >= 8.0, so bundler could resolve an older, incompatible SDK and require 'launchdarkly_observability' would blow up with:

uninitialized constant LaunchDarkly::Interfaces::Plugins

• Bump the gemspec dependency from >= 8.0 to >= 8.11.0.
• Add a load-time guard that raises an actionable LoadError (naming the installed SDK version and the bundle update command) instead of the bare constant error, for anyone already sitting on an old SDK.
• Update the README dependency note.

2. Fix Rails Railtie load-order crash on lazy require

After upgrading the SDK, the customer hit a second error:

NameError: uninitialized constant LaunchDarklyObservability::ControllerHelpers

The Railtie's config.after_initialize block registers via ActiveSupport's lazy load hooks, which run immediately if the :after_initialize event has already fired. The customer required the gem lazily from an autoloaded model (app/models/feature.rb) during a request — i.e. after Rails had booted — so the block executed synchronously while rails.rb was still loading. It referenced ControllerHelpers and the private attach_otel_log_bridge, both defined below the Railtie, so the require crashed. In a normal boot the block is deferred until the file finishes loading, which is why standard setups (and our existing tests) never hit it.

• Move ControllerHelpers / ViewHelpers above the Railtie.
• Move the Railtie's private class methods above config.after_initialize.
• The require is now order-independent regardless of where/when the gem is loaded.

How did you test this change?

• Reproduced the customer's exact ControllerHelpers crash with a regression test that simulates the already-booted condition (immediate after_initialize); it fails on the old ordering and passes on the new one.
• Verified the min-version guard: require succeeds on server-sdk 8.12.2/8.13.0; a simulated 8.8.3 (no Plugins interface) raises the clear LoadError.
• Confirmed default registration paths (explicit project_id and auto-extracted SDK key) work on server-sdk 8.13.0.
• bundle exec rake test → 114 runs, 0 failures, 0 errors.
• bundle exec rubocop on changed files → no offenses.

Are there any deployment considerations?

None — no migrations or data changes. The next launchdarkly-observability release will require server-sdk >= 8.11.0; users on older SDKs were already broken at require time and now get a clear upgrade message. The Railtie reordering is behavior-preserving for normal boots and only fixes the lazy-require case.

---

Note

Low Risk
Targeted dependency floor, load-time guard, and file reordering with regression coverage; normal Rails boots are behavior-preserving.

Overview
This PR fixes two customer-facing compatibility issues in launchdarkly-observability.

Server SDK minimum version: The gemspec, README, and Rails e2e lockfiles now require launchdarkly-server-sdk >= 8.11.0 (plugin APIs landed in 8.11.0). plugin.rb raises a clear LoadError with version and upgrade guidance if an older SDK is loaded at require time.

Rails lazy-load crash: rails.rb is reordered so ControllerHelpers, ViewHelpers, and the Railtie’s private attach_otel_log_bridge helpers are defined before the Railtie and its config.after_initialize hook. When the gem is required after boot, that hook can run synchronously during the file load; the old order caused uninitialized constant LaunchDarklyObservability::ControllerHelpers. A new rails_railtie_test.rb regression test simulates post-boot require with immediate after_initialize.

^{Reviewed by Cursor Bugbot for commit 6bac386. Bugbot is set up for automated code reviews on this repo. Configure here.}