feat!: Add a start wait time option for initialization

[kinyoklion]

Aligns initialization with the OpenFeature provider spec (OFP) start wait requirements, so waiting for the client is bounded instead of unbounded.

• New Provider(Configuration config, TimeSpan? startWait) constructor
• A positive start wait time bounds construction, and InitializeAsync then reports the outcome without waiting again
• TimeSpan.Zero waits nowhere; readiness is reported through provider events
• null waits indefinitely for the data source to become valid or fail permanently
• Breaking: InitializeAsync no longer waits indefinitely after a configured StartWaitTime elapses

Implementation details

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

Describe the solution you've provided

InitializeAsync still registers the flag and data source listeners and checks the current data source status. Only the indefinite mode leaves the initialization task pending; every other mode completes it with the outcome that is known at that point, so initialization does not wait a second time after the LaunchDarkly client constructor has already waited.

The README feature matrix row for initialization and the asynchronous initialization section were updated to describe the three modes.

Describe alternatives you've considered

Interpreting a timeout only inside InitializeAsync would wait twice when StartWaitTime is also configured, and OFP treats the start wait time as a bound over construction plus initialization.

Additional context

Sibling changes for the same OFP requirement: launchdarkly/openfeature-java-server#66, launchdarkly/openfeature-python-server#64, launchdarkly/openfeature-ruby-server#36.

Out of scope, per the audit request: the dependency injection package and the client-side paradigm.

Verified with dotnet test -f net8.0 (71 tests pass).

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

SDK-3285

[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

[kinyoklion]

Devin check this against the latest version of the spec.

[devin-ai-integration]

Devin check this against the latest version of the spec.

Rechecked against the latest OFP spec (launchdarkly/sdk-specs at 7085813, "Clarify OpenFeature provider start wait behavior"). The start wait behavior in this PR still matches 4.3.4–4.3.7; one gap was found and fixed here: the provider stopped reporting status changes after a failed initialization, violating 4.3.3.

• Provider.StatusProvider now takes an initialization-completion signal and suppresses events only up to that point, so 4.2.5 (no event for the transition which completes initialization) still holds while later transitions are emitted.
• A failed initialization records ERROR without duplicating the error event the OpenFeature SDK already emits, and a later recovery to a valid data source emits provider ready.
• Added ItReportsBecomingReadyAfterInitializationFailed.

dotnet test -f net8.0: 72 tests pass.