12A: Answer the conflict questions before anything acts on them

[nikolaystrikhar]

What: adds Conflict\Detector, Conflict\Gatekeeper and Conflict\Redirector and binds all three in the container. No hook is wired here and nothing calls them yet; the step that does arrives in the PR above this one.

Usage:

$container->get( Detector::class )->has_conflict();

$gatekeeper = $container->get( Gatekeeper::class );
$gatekeeper->request_may_resolve() && $gatekeeper->user_may_resolve();

$container->get( Redirector::class )->after_deactivation( $_SERVER['REQUEST_URI'] ?? '' );

Why this way:

Detection is a query, so it stays off the resolver's contract — a host binding its own could otherwise answer "no conflict" and quietly disable the pass.

Two gate methods, because user_may_resolve() pins the current user: asked unconditionally, an SSO plugin's visitors read as signed out on every admin request, so the cheap request gate turns away cron, WP-CLI and every POST first.

On multisite the capability is manage_network_plugins, by name — deactivate_plugins() acts network-wide, and core only widens activate_plugins into it while the Plugins menu is off for sites.

A GET carrying an action is refused along with every POST, since plugins.php?action=activate is the request plugin_sandbox_scrape() replays. Any action arg at all, never a known-safe list.

The redirector answers with the screen requested, not the referrer — only a validated basename and a re-encoded query leave it, with admin_url(), network_admin_url() or user_admin_url() in front.

[d4mation]

I don't know if this would ever actually be used in practice, but it is harmless and could account for a weird edge case we aren't considering I suppose.