12E: Resolve a standalone conflict behind an interface a host can rebind

[nikolaystrikhar]

What: adds Conflict\Resolver behind Conflict\Contracts\Resolver_Interface, the Provider binding and the Absorber::resolver() accessor.

Usage:

$container->singleton( Resolver_Interface::class, My_Resolver::class );

Absorber::resolver()->resolve_all();

Why this way:

Nothing wires it in this PR. The plugins_loaded step that runs it lands at the priority ahead of the load pass, and separating the class from its timing keeps the seam a host rebinds reviewable on its own.

An unrecognised policy normalises to the branch that only queues a notice. Conflict_Policy::is_valid() decides before the switch, so a typo like 'defered' — in an option a host persisted, or in whatever the filter returned — is never read as consent to turn off a plugin the site owner deliberately turned on.

Every collaborator is a constructor argument with no default — the registry reader, the detector, the deactivator, the notice queue and the redirector — so the object a test builds is the object the provider builds, and a host's rebinding of either plugin seam reaches it without the resolver knowing a container exists.

[d4mation]

Being able to rebind this from the Host Plugin could be super powerful 👀