fix: activate plugin hooks before RegisterPlugin calls Register

[abelonogov-ld]

Summary

LdClient.RegisterPlugin merged a plugin's hooks into the live pipeline only after Register returned. Construction-time registration does the opposite: GetPluginHooks feeds the Executor constructor before RegisterPlugins runs. The result was that the same plugin saw different hook behaviour depending on how it was registered, which a plugin author has no way to reason about — and which matters for plugins like observability that support both paths.

This reorders RegisterPlugin to add the hooks first. The previous ordering was deliberate and documented as a deviation, so this is a behaviour change rather than a bug fix in the narrow sense:

• A plugin's own hooks now observe the flag evaluations and identify calls its Register makes.
• A plugin whose Register throws now keeps its hooks, exactly as a configured plugin's do. Executor.Dispose already disposes every hook in the pipeline when the client is disposed, so the hooks are still cleaned up and DisposePluginHooks is no longer needed.
• GetHooks throwing is unchanged: the plugin is not registered and contributes no hooks.

This brings .NET in line with the iOS, Android, and Flutter SDKs, which all activate plugin hooks before register.

Test plan

RegisterPlugin had no test coverage, so this adds it:

• RegisterPluginRegistersPluginAndItsHooks — the client and environment metadata reach the plugin, and its hooks go live
• RegisterPluginRunsTheRegisteringPluginsOwnHooks — a plugin that evaluates a flag inside Register sees its own hook fire, and it keeps firing afterwards
• RegisterPluginKeepsHooksWhenRegisterThrows — hooks stay live when Register throws, and the exception does not propagate
• RegisterPluginDoesNotRegisterPluginWhoseGetHooksThrows — Register is not reached
• RegisterPluginRejectsNullPlugin
• Full client suite green: 385 passed, 0 failed

---

Note

Overview
LdClient.RegisterPlugin now merges plugin hooks into the live pipeline before calling Register, aligning runtime registration with plugins added via ConfigurationBuilder.Plugins (hooks first, then register). Flag evaluations and identify calls made inside Register therefore invoke that plugin’s hooks, matching iOS/Android/Flutter.

If Register throws, hooks remain active (same as a configured plugin whose Register fails); the previous DisposePluginHooks path on register failure is removed—cleanup happens when the client disposes the hook executor. GetHooks failures still abort registration with no hooks added.

Adds RegisterPlugin test coverage (hooks live, hooks during Register, Register / GetHooks failures, null rejection) plus supporting test plugins.

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

[tanderson-ld]

Unused?