fix(ruby): silence observability plugin warnings (log bridge, nil context id, instrumentation options)

[ccschmitz-launchdarkly]

Summary

Follow-up to #575. A customer integrating the Ruby observability plugin reported a flood of warnings/errors in their logs after traces started flowing. The most urgent one — the nil feature_flag.context.id OTel error — shipped separately in 0.2.2 (#641). This PR carries the rest of the fixes (each with a regression test), sharpens how invalid contexts surface on the trace, closes the e2e gap that let them through, and de-flakes the railtie test.

Diagnosed from the customer's log dump:

Log line	Cause	Fix
Could not attach log bridge to Rails.logger: undefined method 'otel_logger_provider_available?'	Railtie's after_initialize runs synchronously during a lazy (post-boot) require, before the module method it delegated to was defined	Inline the check in the Railtie; move the rails.rb require to the bottom of the main file
Instrumentation ... ignored the following unknown configuration options [:db_statement] / [:enable_recognize_route]	Options that don't exist on the pinned instrumentation versions	Remove them (route naming is automatic via ActionPack; SQL capture is via the DB adapter instrumentations)

The OpenTelemetry error: invalid ... attribute value type NilClass for key 'feature_flag.context.id' line is already fixed and released in 0.2.2 (#641). This PR builds on top of that fix.

Better invalid-context diagnostics

A nil feature_flag.context.id (the thing #641 silenced) is itself a signal: that evaluation ran against an invalid context and fell back to the flag's default value. Two changes make that legible on the trace instead of silent:

• USER_NOT_SPECIFIED now maps to the OpenTelemetry feature-flag error.type = invalid_context. It was provider_not_ready, which is misleading — the provider is fine, the context isn't; provider_not_ready is now reserved for CLIENT_NOT_READY.
• The span's error.message now includes the context's own validation reason (e.g. Flag evaluation error: USER_NOT_SPECIFIED (context kind must be a string)), recovered from LDContext#error. The SDK's validation messages are static and structural — never key/kind/attribute values — so no context data is leaked.

De-flake the railtie test

otel_logger_provider_available? began with defined?(...), which returns a string or nil — so when OpenTelemetry::SDK::Logs wasn't loaded yet, the && chain returned nil instead of false and the railtie regression test (which asserts true/false) flaked ~3/8 runs depending on test order. Both copies of the predicate — the Railtie's inlined one and the module-level one — now guard the constant first and return a strict boolean.

Tests

• Gem suite: regression tests for the log-bridge load order and the new invalid-context error.type/message. 118 runs, 0 failures across repeated runs; rubocop clean.
• e2e: new ObservabilityInstrumentationTest in the Rails demo app asserts the Rails-family instrumentations report installed? == true after boot (the inverse of "failed to install") and that a request produces a server span. The demo app only ever exercised the boot-time-init happy path, which is why this slipped through.

Not included (follow-up)

The Instrumentation: ... failed to install warnings are a separate issue: the plugin configures auto-instrumentation from Plugin#register (at LDClient.new), so when a client is created lazily after Rails boots, the Rails instrumentations' ActiveSupport.on_load hooks have already fired. Fixing that (install instrumentation during Rails boot) plus a lazy-init e2e variant is tracked separately.

🤖 Generated with Claude Code