22: Redirect only where a standalone really did go away

[nikolaystrikhar]

What: Conflict\Resolver's DEACTIVATE branch re-asks Conflict\Detector after deactivating, so the plugins_loaded priority 5 step only reports success — and only redirects — when the standalone is genuinely gone.

Usage:

// A site that puts the standalone back now gets the merge notice,
// where before it got a redirect loop out of wp-admin.
add_filter( 'option_active_plugins', $forces_the_standalone_active );

Why this way:

Deactivating is not the same event as being deactivated. The branch returned true the moment deactivate() returned. Three realistic sites disagree with that: one filtering option_active_plugins, one that rebound Deactivator_Interface to something that no-ops, one whose rebound Checker_Interface means by "active" something deactivate_plugins() never touches.

The redirect is what made it unrecoverable. Every admin GET resolved, redirected to itself and repeated until the browser gave up, and because each request exits before all_admin_notices the notice explaining it was never drawn. Suppressing the redirect leaves the notice to render on a page that actually loads.

The detector is already a constructor argument, so the second ask adds no dependency and stays inside the per-sub-plugin try.