feat: implement waitForInitialization for browser sdk 4.x

[joker23]

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

• feat: adding waitForInitialize to browser 4.x
• test: adding unit tests for waitForInitilization

Describe the solution you've provided

Added waitForInitialization function to browser 4.x implementation.

Additional context

• I kept the method signiture the same as 3.x but am open to updating it to align with what we have in the server sdks f({timeout: 5}) instead of f(5)
• I "simplified" the way we are tracking for the initialization state to a boolean. It looks like our new identification would not be throwing which minimizes the reject conditions... I can add those back in case we get an error status returned? At that point we might want to just wait for the timeout to throw.
• I put in a default 5 seconds timeout on the wait
• I also added in an initialized event that a successful identify will emit, I figured that would be a way for developers to know if LDClient initialized even if the initialization goes past timeout.

---

Note

Introduces waitForInitialization to the browser client with a configurable timeout and explicit success/failed/timeout results, and emits an initialized event on successful identify, with comprehensive tests.

• Browser SDK:
  • Initialization API: Add waitForInitialization(options) to LDClient with default 5s timeout, returning complete | failed | timeout results; supports multiple calls and immediate return if already resolved.
  • Timeout handling: Use cancelableTimedPromise and internal _promiseWithTimeout to race initialization vs timeout.
  • Identify integration: identifyResult now resolves the initialization promise as complete or failed and starts goal tracking.
  • Events: Add "initialized" event to emitter and emit it on successful identify.
  • Types: Define LDWaitForInitializationOptions/Result types and expose method in public client; wire through makeClient.
• Compat:
  • Exclude waitForInitialization from the compat LDClient interface.
• Tests:
  • Add unit tests for waitForInitialization covering success, timeout, and failure (before/after calling).

^{Written by Cursor Bugbot for commit 262c6fe. This will update automatically on new commits. Configure here.}

[github-actions]

@launchdarkly/browser size report
This is the brotli compressed size of the ESM build.
Compressed size: 169118 bytes
Compressed size limit: 200000
Uncompressed size: 789399 bytes

[github-actions]

@launchdarkly/js-sdk-common size report
This is the brotli compressed size of the ESM build.
Compressed size: 25394 bytes
Compressed size limit: 26000
Uncompressed size: 124693 bytes

[github-actions]

@launchdarkly/js-client-sdk size report
This is the brotli compressed size of the ESM build.
Compressed size: 22417 bytes
Compressed size limit: 25000
Uncompressed size: 77391 bytes

[github-actions]

@launchdarkly/js-client-sdk-common size report
This is the brotli compressed size of the ESM build.
Compressed size: 17645 bytes
Compressed size limit: 20000
Uncompressed size: 90305 bytes

[cursor]

Bug: Stale initialization state persists across multiple identify calls

The _initializeResult state is set when an identify call completes but is never reset when a new identify starts. If a user calls identify successfully, then calls identify again for a different context, and then calls waitForInitialization, the method will immediately return the stale result from the first identify rather than waiting for the in-progress second identify to complete. The initialization state (_initializeResult, _initializedPromise, and _initResolve) needs to be reset at the start of each identifyResult call.

Additional Locations (1)

• packages/sdk/browser/src/BrowserClient.ts#L247-L251