feat(events): add flushAndWait on Apple (tier 2)

[abelonogov-ld]

Tier 2 of the mobile event durability work. It stacks on tier 1 (#530), and nothing here persists events; that is tier 3.

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

Stacked on #530. Android already has the equivalent LDClient.flushAndWait(long, TimeUnit).

Describe the solution you've provided

A bounded flush: LDClient.flushAndWait(timeout:) spends up to a caller-supplied budget trying to deliver, then reports whether the events left the SDK's hands. Seconds, to match identify and start; ObjcLDClient.flushAndWait(timeout:) exposes it to Objective-C.

• EventReporting.flushReportingOutcome is the seam. It reports true when the events were delivered, refused for good, or there were none, and false when the SDK is offline or a retryable failure means they are still waiting.
• Response classification is now a decision rather than a Bool. processEventResponse returns settled, retryable, or dropped — the three outcomes its two callers already implied — which is what lets the flush say which one happened.
• No deadlock from the main thread. TimeoutExecutor bounds the wait, and completions run on a queue that is neither main nor the reporter's delivery queue, so a lifecycle caller on the main thread cannot end up waiting for itself.
• Backgrounding tries to deliver. It runs the delivery inside a ProcessInfo.performExpiringActivity assertion (BackgroundActivity), so the system does not suspend the process under a request that has only just reached the network. UIApplication.beginBackgroundTask is not available because the framework is built extension-safe.

Describe alternatives you've considered

• An SDK-installed crash hook that flushes. Not done: the SDK has no crash hook of its own on Apple, and a Mach exception handler is not a supported caller. This is not a crash-time API, and its documentation says so.
• Reporting delivery as a plain Bool from the response handler. It could not distinguish a permanent refusal (settled, nothing to retry) from a retryable failure, and the flush has to tell them apart.

Additional context

Spec: Event Durability §8–§12 (recoverable failure: bounded flush, response classification, lifecycle hooks, and the honesty requirement that flushAndWait is not a promise under termination).

Made with Cursor

[cursor]

Stale Bugbot comment from a previous run.

[cursor]

Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.

There are 2 total unresolved issues (including 1 from previous review).

^{❌ 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 dc9d1e6. Configure here.}

[cursor]

Current version of PR was reviewed by /review-bugbot on Oct 1, 13:41 PDT. It flagged 0 findings.

^{Bugbot on commit 47700b3 is skipped.}