Summary

Re #91873. After upgrading to 2026.6.x, a Slack (or any global/config-origin) channel that the user had configured under channels.* but did not list in plugins.allow (or enable via plugins.entries.<id>.enabled) is dropped by the plugin trust gate — and the gateway startup is completely silent about it. The user sees the ready banner (http server listening (N plugins: ...)) with no error, no warning, and their Slack channel just stops working. The reporter confirmed the workaround is plugins.allow=["slack"].

The trust gate itself (channel-presence-policy / gateway-startup-plugin-ids) is intentional and unchanged here — whether to restore implicit loading for upgraded configs is a product decision and is out of scope for this PR. This change only makes the silent drop loud, which is what reviewers asked for on the issue ("surface blocked configured channels in gateway startup/status/doctor before users miss messages").

Changes

• src/gateway/server-startup-log.ts — logGatewayStartup now reuses the existing doctor blocker scan (scanConfiguredChannelPluginBlockers / collectConfiguredChannelPluginBlockerWarnings) and emits a startup warning for each configured channel that was blocked from loading, e.g. configured channel not loaded: channels.slack: <reason>. Add plugins.entries.slack.enabled=true .... Wrapped in try/catch — the warning is advisory and never blocks startup. No change to trust-gate semantics, no restored implicit loading, no fallback shim.

Real behavior proof

Behavior addressed: a configured-but-untrusted channel that the gateway drops now produces a startup warning instead of disappearing silently.

Real environment: local, Node v22. Drove the real logGatewayStartup → real scanConfiguredChannelPluginBlockers / blocker-warning collection → real trust-gate decision (evaluateEffectiveChannelPlugin), with only the on-disk manifest discovery injected via the project's standard test seam (vi.spyOn(loadPluginManifestRegistry) with a real global-origin slack manifest record).

Evidence (before/after, real functions):

pre-fix (real source via git stash):  warnings for channels.slack = []        → SILENT (reproduces the bug)
post-fix:                             warnings for channels.slack = 1 warning  → "configured channel not loaded: channels.slack: ... Add plugins.entries.slack.enabled=true ..."
with plugins.allow=["slack"]:         no warning (channel loads)

Observed result: the blocked channel is surfaced at startup after the fix; the pre-fix function emits nothing. A trust-pre-check (resolveConfiguredChannelPresencePolicy) confirms global-origin slack is effective:false / blockedReasons:["untrusted-plugin"] without plugins.allow and effective:true once it's listed — matching the reporter's workaround exactly.

What was not tested: no live Slack connection (not needed — this is the config/discovery/startup-logging path); restoring implicit auto-load is deliberately not attempted (product decision).

Tests and validation

• src/gateway/server-startup-log.test.ts (+2): warns with channels.slack + the enable hint when the channel is blocked; no warning once plugins.allow includes it. 10/10 pass.
• Negative control: reverting the change makes the positive test fail (empty warnings = silent), confirming the warning comes from this fix.
• npx oxlint --import-plugin clean on both changed files.