12F: Wire the conflict step, and move the load pass behind it

[nikolaystrikhar]

What: Boot\Scheduler wires conflict resolution at plugins_loaded priority 5 and moves the load pass to priority 6, with the too-late barrier now measuring against the lowest priority in the sequence.

Usage:

add_action( 'plugins_loaded', static function (): void {
    Config::set_container( give()->container );
    Absorber::boot();
}, 0 );

Why this way:

Both gates and the conflict probe live in the step, not the resolver, so a host binding its own Resolver_Interface cannot drop one by omission — and a request that fails any of them never builds a resolver.

The gates sit either side of the probe. current_user_can() resolves and caches the current user, so asking it on every admin GET would settle who is signed in ahead of an SSO or JWT plugin adding its determine_current_user filter from its own plugins_loaded callback. The detector reports and changes nothing, so the cheap question goes first.

The barrier measures against the first step, not the last. Measuring against the load would let a host wire the load and silently lose the conflict pass, which is the half a fatal depends on.

Resolution sits at 5, not 1, so the barrier leaves a host somewhere to stand. At 1 the only slot left was 0, and LearnDash and MemberDash both wire Harbor's set_container() at priority 1 — a host copying that habit landed exactly on the barrier and silently took the inline fallback.

[d4mation]

Realizing this now while reviewing this PR. Commenting here so I can revisit it later:

With the way this is currently written, a Standalone plugin is never deactivated until an Admin request is made.

This could result in an edge case where:

1. Standalone plugin is active
2. Sub Plugin for it is included in the Host Plugin in a new update
3. That update is applied via SFTP/Composer/etc.
4. An Admin request is never made

In this scenario, the Standalone plugin is always active and the Sub Plugin never loads. Effectively, the Deactivate Conflict Policy falls back to Defer.

While an edge case, if an Admin request is never made and the Host Plugin continues to get updates which update that Sub Plugin, it could result in "missing functionality".

That said, this implementation is safer because the way it is being handled in other repos could have resulted in weird edge cases where a redirect and exit could have broken cron or other similar tasks (temporarily) for that request.

Maybe there's a way to get a best-of-both-worlds. 🤔

[d4mation]

Thought this over a bit and it'll be a larger/more complex change. It is better to merge this for now and revisit as its own PR for sure.