feat: Add environment ID support for hooks

[kinyoklion]

Requirements

• I have added test coverage for new or changed functionality
• I have followed the repository's pull request submission guidelines
• I have validated my changes against all supported platform versions

Related issues

Part of the cross-SDK work to expose the LaunchDarkly environment ID on hook contexts, per the hooks and OTEL specs. Equivalent implementations: launchdarkly/dotnet-core#81, launchdarkly/python-server-sdk#484, launchdarkly/cpp-sdks#594.

Describe the solution you've provided

EvaluationSeriesContext gains an optional environment_id, populated by LDClient from the active data system:

Interfaces::Hooks::EvaluationSeriesContext.new(key, context, default, method, @data_system.environment_id)

Both data systems now report it, so the value is only visible once LaunchDarkly has actually answered:

• FDv1 — X-LD-EnvID is read from the streaming connection response headers (SSE::Client#on_connect) and from polling responses (Requestor#request_all_data_with_headers), then recorded on the data source UpdateSink, which the FDv1 data system exposes.
• FDv2 — the ID was already parsed into Basis/Update by the polling and streaming data sources but discarded; the FDv2 data system now latches it from a successful initializer basis and from VALID synchronizer updates. This also covers the FDv1 fallback synchronizer, which reports headers the same way.

Error responses, missing headers, and empty header values are ignored and never clear a previously known ID.

The contract test service reports environmentId on the evaluation series context and declares the hook-environment-id capability.

Describe alternatives you've considered

A shared environment-ID holder threaded into each data source was rejected as a side channel; carrying the value with the data/response metadata matches the other SDKs and the existing FDv2 Basis/Update shape.

Additional context

• No ld-eventsource change is needed: SSE::Client#on_connect already yields the successful response headers on every connection and reconnection.
• hooks/evaluation/provides the environment ID passes against the released v2.39.0 harness (default/streaming and polling modes). The repo's v3 contract-test run is pinned to v3.0.0-alpha.6, which predates that test; bumping the pin can be a separate ci: change.
• ruby-server-sdk-otel's tracing hook only uses the configured environment ID today; adding the series-context fallback is a follow-up in that repo.

Link to Devin session: https://app.devin.ai/sessions/bfe54128e2804a96bb100e6120e9a3ef
Requested by: @kinyoklion

---

Note

Overview
Evaluation hooks now get an optional environment_id on EvaluationSeriesContext, filled from the active data system after LaunchDarkly reports it.

FDv1 reads X-LD-EnvID from streaming connect headers and polling responses (request_all_data_with_headers) and stores it on the data-source update sink. FDv2 latches the ID from a successful initializer Basis and from VALID synchronizer updates (it was already on those types but unused). Missing, empty, or error-path values are ignored and never clear a known ID.

Contract tests declare hook-environment-id and include environmentId in hook callbacks. CI v3 contract tests now pin to v3 instead of v3.0.0-alpha.6.

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

[devin-ai-integration]

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

• Address comments on this PR. Add '(aside)' to your comment to have me ignore it.
• Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

• Disable automatic comment, CI, and merge conflict monitoring

[devin-ai-integration]

@cursor review