30: Drive the requests the gate must refuse, end to end

[nikolaystrikhar]

What: seven end-to-end scenarios in Scenario\ConflictTest and Scenario\LoadTest, plus pin_headers_as_sent() on the base case and the matching entries in tests/README.md.

Usage:

// A visitor's request reaches the library and still leaves the site alone.
set_current_screen( 'front' );
$this->run_request();
$this->assertSame( [ self::STANDALONE ], $this->active_plugins() );

Why this way:

Every scenario was an admin GET on the plugins screen. So the library's worst possible failure — deactivating a plugin and exiting on a visitor's request, or aborting the activation core replays through plugin_sandbox_scrape() — rested entirely on unit tests of Conflict\Gatekeeper and on nothing that ran a request.

The late-boot scenario takes its ordering from WordPress, not from us. It records update_option_active_plugins and the activation callback and asserts the sequence, which is what reaches Conflict\Resolver::redirect()'s headers_sent() branch through the real fallback rather than through a unit test of it.

Each new scenario pairs with a branch that was passing for the wrong reason — the detector's first-entry loop, the registry buffer, the duplicate slug — so the end-to-end claim and the unit claim fail independently.