feat: add registerPlugin so a plugin can be added after the client starts

[abelonogov-ld]

Summary

Plugins could only be supplied through LDConfig, so an integration that learns about a plugin later — or that wants to instrument a client it did not configure — had no way in. This adds LDClient.registerPlugin(Plugin), mirroring the method the .NET and Flutter SDKs already expose.

• Hooks go live only once register succeeds. This follows the .NET ordering, and it differs from configuration-time registration, where a plugin's hooks are active before register is called. The consequence is that a plugin whose registration failed never contributes hooks, and a plugin's own hooks do not observe the evaluations or identify calls its register makes.
• EnvironmentMetadata is now retained on the instance rather than living in a local map during init, so a plugin registered later is handed the same environment description as one configured up front. The init loop switches from a Map<LDClient, EnvironmentMetadata> to a List<LDClient> accordingly.
• Failures are contained. A throwing getHooks leaves the plugin unregistered; a throwing register yields a failure result passed to onPluginsReady. Neither propagates to the caller. Reading the plugin's name for the log message tolerates metadata that itself throws, so reporting one failure cannot raise another out of the handler reporting it.

Registration applies to the one client it is called on, so a multi-environment setup means calling it per environment.

Test plan

Eight cases added to LDClientPluginsTest, all passing on an API 36 emulator alongside the three pre-existing plugin tests (11 total):

• registerPluginPassesClientAndEnvironmentMetadata
• registerPluginActivatesBundledHooks
• registerPluginDoesNotRunTheRegisteringPluginsOwnHooks
• registerPluginReportsSuccessToOnPluginsReady
• registerPluginDoesNotRegisterPluginWhoseGetHooksThrows
• registerPluginToleratesRegisterThrowing
• registerPluginRejectsNullPlugin
• registerPluginAppliesOnlyToTheClientItIsCalledOn
• testDebugUnitTest green

---

Note

Overview
Adds LDClient.registerPlugin(Plugin) so integrations can attach plugins after the client is created, aligned with other LaunchDarkly mobile SDKs. EnvironmentMetadata is kept on each client instance so late registration gets the same environment description as config-time plugins.

Plugin registration is unified in a private registerPlugins path used by both LDConfig plugins at init and registerPlugin. For each plugin: getHooks, then register, then all successful hooks are activated in one batch via new HookRunner.addHooks. Hooks are not active during any plugin’s register call, and plugins that throw from getHooks or register contribute no hooks (errors are logged only). Init-time registration still invokes deprecated onPluginsReady for the configured batch; registerPlugin does not call it and applies only to the client it was invoked on.

Plugin.onPluginsReady is marked @Deprecated. Instrumentation tests cover failure isolation, hook timing, metadata, null rejection, and multi-environment scoping.

^{Reviewed by Cursor Bugbot for commit 0940c6b. Bugbot is set up for automated code reviews on this repo. Configure here.}

[tanderson-ld]

This deprecation reason should not talk about specific usages of the abstract class.

You can just say "onPluginsReady was necessary in the past, but has since been determined to be problematic and is being removed in the next major version."

[cursor]

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

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