Summary

Avoid loading unrelated core legacy-migration detectors during a provably pristine Gateway startup.

Problem to solve

A first Gateway start with an otherwise pristine state directory still enters the full core legacy-state discovery graph when the config contains local plugins. That discovery imports bundled channel migration detectors and setup modules even though there is no core state to migrate. The cost grows with plugin-heavy configurations and delays readiness on every newly provisioned instance.

Proposed solution

Capture whether core state is physically pristine before Gateway selection can create runtime files, carry that prepared fact through the existing bootstrap seam, and use the plugin-only doctor migration path when plugin configuration still requires inspection. Keep the full migration path for existing core state, external session stores, includes, or other stateful core configuration.

Alternatives considered

• Skipping all migrations is unsafe because configured plugins may own doctor migrations.
• Caching detector results leaves request-time discovery in place and weakens lifecycle ownership.
• Loading core detectors lazily still pays for unrelated bundled channel modules on the first start.

Impact

• Affected: operators provisioning Gateways, especially plugin-heavy configurations.
• Severity: startup latency only; no steady-state behavior change.
• Frequency: each first start against a pristine state root.
• Consequence: delayed HTTP listen/readiness and unnecessary module loading.

Evidence/examples

Controlled seven-run Blacksmith Testbox A/B measurements (two warmups, p50):

• 50 manifest plugins: /readyz 4911.3 ms -> 4242.9 ms (-13.6%); bootstrap 2711.2 ms -> 2289.9 ms (-15.5%).
• 50 startup-lazy plugins: /readyz 4603.2 ms -> 4287.0 ms (-6.9%); bootstrap 2741.9 ms -> 2426.6 ms (-11.5%).
• Default config: /readyz 3184.7 ms -> 3039.7 ms (-4.6%); bootstrap remained flat (143.7 ms -> 143.1 ms).

Regression coverage verifies that external session stores and other stateful core configuration still force core migration discovery, while plugin-owned migrations continue to run.

Additional information

This uses the existing migration ownership boundary. It adds no config, protocol, persistence, or compatibility surface.