fix: Resolve initialization immediately when a start wait time was used

[kinyoklion]

BEGIN_COMMIT_OVERRIDE
chore: Resolve initialization immediately when a start wait time was used
END_COMMIT_OVERRIDE

Change to chore as it is being reverted.

A positive StartWaitTime no longer causes a second wait during provider initialization.

• The provider constructor already blocks in the LdClient constructor for the start wait time, so InitializeAsync now completes with the outcome instead of scheduling its own timer; a 5 second start wait no longer means up to 10 seconds before SetProviderAsync resolves.
• A zero StartWaitTime is unchanged: no timeout, initialization completes when the data source becomes valid or fails permanently.
• The failure message changed to the client did not become ready within the {n}ms start wait time.

Implementation details

Follow-up to #60, which introduced the timeout. ScheduleInitTimeout is replaced by FailInitializationIfNotReady, called at the end of InitializeAsync when a start wait was configured:

if (_startWait.HasValue)
{
    FailInitializationIfNotReady(_startWait.Value);
}

The provider still keeps listening for data source status after failing, so a later successful connection emits a ready event and evaluations are never short-circuited.

Testing: dotnet test test/LaunchDarkly.OpenFeature.ServerProvider.Tests -f net8.0. The timeout test now asserts the immediate failure, and the "does not time out when the client becomes ready" test covers a client which is ready when initialization is requested.

Related spec change: https://github.com/launchdarkly/sdk-specs/pull/257

Link to Devin session: https://app.devin.ai/sessions/0c452d209ec54b068ba120b4c92b8f6c
Open in Devin Desktop: https://app.devin.ai/desktop/session/0c452d209ec54b068ba120b4c92b8f6c?variant=devin
Requested by: @kinyoklion

---

Note

Overview
Fixes double-wait on provider startup when StartWaitTime is greater than zero. The LaunchDarkly client already blocks in the provider constructor for that duration; InitializeAsync no longer schedules a second timer, so a 5s start wait no longer stretches toward ~10s before SetProviderAsync completes.

When a start wait is configured and the client is still not ready after construction, InitializeAsync fails synchronously with an updated message (the client did not become ready within the {n}ms start wait time). Background reconnection is unchanged—a later successful connection can still emit a ready event. StartWaitTime of zero still means non-blocking construction and async initialization until the data source is valid.

README initialization notes are aligned with this behavior; unit tests assert immediate failure and the ready-client success path.

^{Reviewed by Cursor Bugbot for commit 75a45cd. 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