fix!: Use None rather than zero for indefinite initialization waiting

[kinyoklion]

Aligns start_wait with the OpenFeature provider spec (OFP), which requires a distinct non-duration value to request indefinite initialization waiting.

• start_wait=None now requests an indefinite wait: the constructor does not block and initialize waits until the data source becomes valid or fails permanently.
• start_wait=0 no longer waits indefinitely; it waits nowhere, so initialize reports a failed initialization unless the client is already ready, and readiness is observed through provider events.
• Positive values are unchanged: the constructor bounds the wait and initialize returns immediately with whatever the outcome is.
• Breaking for anyone relying on 0 meaning "wait forever".

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

None.

Implementation details

OFP requires that a positive start wait bound total construction plus initialization, that zero wait nowhere, and that indefinite waiting avoid construction-time blocking and instead wait during initialize. Previously zero was overloaded to mean indefinite, leaving no way to express "no waiting at all".

None is now passed to LDClient as a zero construction wait, with the waiting performed in initialize against the data source status listener.

Testing: make test (88 tests) and make lint (mypy) pass. New tests cover the zero and indefinite cases, including that the constructor does not block when None is given.

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

---

Note

Overview
Breaking: start_wait now matches the OpenFeature provider spec—0 means no waiting anywhere; indefinite waiting uses None instead of 0.

With start_wait=0, the constructor and initialize do not block on the data source; initialize raises unless the LD client is already ready, and later readiness is surfaced via PROVIDER_READY (and related) events. With start_wait=None, construction still passes 0 to LDClient, but initialize waits without a deadline until the data source is valid or permanently fails. Positive start_wait behavior is unchanged.

Provider event emission is reworked: status is tracked with ProviderStatus, listeners are registered before the init wait, and the status change that completes OpenFeature initialization is not duplicated as a provider event—subsequent transitions (including recovery after a failed init with start_wait=0) are emitted. README and tests cover the new semantics, including DelayedReadyDataSource and post-failure ready events.

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

[kinyoklion]

Devin check this against the latest version of the spec.

[cursor]

Cursor Bugbot has reviewed your changes using default effort and found 2 potential issues.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 6385f3e. Configure here.}

[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 semantics in this PR still match 4.3.4–4.3.7; the gap found was 4.3.3, the provider must keep reporting status changes after initialization has failed.

• The data source and flag listeners now stay registered after a failed initialization, and provider status is tracked so only genuine transitions are emitted.
• The initialization outcome is recorded and initialization completed under the same lock, so the OpenFeature SDK's own event for the initialization outcome is not duplicated (4.2.5) and a concurrent data source change cannot be dropped.
• Added test_ready_is_reported_after_initialization_failed.

poetry run pytest -q: 89 pass. poetry run mypy ld_openfeature tests: clean.