Bug fixed. Dependency inverted. Pre-existing flaky test fixed

[Ni7ram]

Problem

Users who held only a reference to SplitClient (releasing the SplitFactory) could
experience the SDK never reaching .sdkReady. The factory was the sole strong owner of
SplitClientManager, which in turn owned eventsManagerCoordinator, syncManager and
all the infrastructure required to drive the client to ready. Once the factory was
released, everything died and the client became inert.

A workaround existed in SplitEventActionTask, which kept a strong factory: SplitFactory
property purely to keep the factory alive via the cycle
factory → clientManager → eventsManagerCoordinator → eventsManager → task → factory.
This worked only as long as the user registered at least one event listener and coupled
an event-running task to factory ownership.

Changes

This PR replaces the workaround with a direct ownership change:

• DefaultSplitClient.clientManager: weak → strong (let). The client now keeps its
  client manager (and the rest of the infra) alive on its own.
• SplitEventActionTask.factory removed (and from all call sites).
• SplitClientManager.splitFactory removed (only consumer was the task workaround).
• LocalhostSplitClient.clientManager removed (was unused).
• All mocks/stubs and tests updated accordingly.

Existing cycles between DefaultClientManager ↔ defaultClient and through
byKeyRegistry are preserved by design; they get broken by destroy() exactly as
before, so no leak semantics change. The difference is that the cycle now reflects the
real ownership model rather than an opaque workaround.

Bonus

Fixes a pre-existing flaky test in LocalhostTests.testUsingYamlFromApi: the
.sdkUpdated listener was being registered after updateLocalhost(yaml:) was called,
which meant the event could fire before the listener was attached and be silently
dropped by DefaultSplitClient.on(event:)'s eventAlreadyTriggered guard. Reordered to
register first, trigger second.