fix: Reuse an in-flight big segment status poll instead of querying twice

[jsonbailey]

BEGIN_COMMIT_OVERRIDE
fix: Reuse an in-flight big segment status poll instead of always querying twice
END_COMMIT_OVERRIDE

The status getter polled the store whenever no status was cached yet, so a request arriving while the startup poll was still in flight started a second metadata query of its own. get_context_membership had the same inline poll, and now routes through get_status so the cache check lives in one place.

Status requests now wait on the same Mutex the poll task holds and re-check the cached status after acquiring it, so a poll that is already running satisfies them instead of being duplicated. Observers are notified outside the lock — a listener calling back into the manager would otherwise deadlock on Ruby's non-reentrant mutex.

The poll schedule is unchanged — the first poll still fires immediately, and the RepeatingTask timing arguments are untouched.

Matching change in Python: launchdarkly/python-server-sdk#535

Test evidence

Two regression specs added in spec/impl/big_segments_spec.rb, one per entry point (the status getter and get_context_membership). The store signals when it has entered a metadata query and then stays there, so the request is forced to overlap an in-flight poll rather than relying on timing; each asserts exactly one metadata query. Both fail with expected: 1, got: 2 against the code on main.

Unit suite: 1108 examples, 0 failures. RuboCop: 188 files, no offenses. v2 contract tests: 4703 total, 15 skipped, all passed — including all seven big segments/status polling tests.

Tracked Internally: SDK-3212

---

Note

Overview
Fixes duplicate big segment store metadata queries when a status or membership read happens while the startup (or in-flight) poll has not finished yet.

BigSegmentStoreManager now serializes status fetches with a Mutex: callers double-check @last_status after acquiring the lock and only run one store query if still empty. get_context_membership no longer triggers its own inline poll and always goes through get_status. Store querying is split into query_store_status (cache only, under the lock); update_status / observer notification runs outside the lock to avoid deadlock if a listener re-enters the manager.

Regression specs force overlap between the background poll and a status or membership request and assert exactly one get_metadata call.

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