Summary

• Problem: later prepared-runtime migrations need loaded provider, channel, public metadata, and outbound adapter facts from Gateway startup, but those facts were not exposed through one stable loaded-runtime surface.
• Why it matters: without this startup/public metadata layer, later reply, tool, outbound, TTS, and command PRs would either keep broad request-time rediscovery or add scattered cache layers around individual consumers.
• What changed: this PR makes Gateway startup and plugin runtime state expose loaded/public runtime metadata, pins the Gateway runtime registry beside the channel registry, expands startup plugin selection for configured model/media/speech facts, and lets selected-provider handle lookup reuse the gateway-runtime loaded registry surface.
• What did NOT change: this PR does not migrate reply/tool/outbound request-time consumers yet and does not remove compatibility fallback behavior needed by setup, startup, admin, standalone, or later migration surfaces.

Change Type (select all)

• Bug fix
• Feature
• Refactor required for the fix
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Related Tracking: Prepared runtime resolution migration #77700
• This PR fixes a bug or regression

Details

This is PR 2 in the prepared runtime resolution migration.

It adds the loaded-runtime metadata layer that later migration PRs can consume without rebuilding plugin/provider/channel registries at request time:

• Active runtime registry lookup now has explicit surfaces for active, channel, Gateway runtime, and HTTP route registries.
• Gateway startup pins both channel and Gateway runtime registries so later config-schema or status registry churn cannot evict the runtime facts prepared during startup.
• resolveProviderRuntimePluginHandle(...) now checks the gateway-runtime loaded registry surface introduced here, completing the PR 1 follow-up called out in Tracking: Prepared runtime resolution migration #77700.
• Runtime plugin metadata exposes loaded provider/channel/public facts needed by later prepared-runtime consumers.
• Startup plugin id selection includes configured model owner plugins, configured media model owners, configured speech providers, and bundled startup sidecars without broad request-time loading.
• Bundled channel metadata and outbound adapter loading can answer lightweight public-runtime questions without full channel plugin bootstrap.
• Web provider public/runtime artifacts reuse the loaded/public metadata path.
• Tool-result middleware loading checks prepared runtime registries before falling back to broader plugin loading.

The architectural line is the same as PR 1: this PR creates startup/runtime producer surfaces only. It does not redirect normal reply/tool/outbound consumers yet. Later PRs will migrate one surface at a time, prove that prepared facts are used, and remove old lookup branches only after the corresponding prepared path owns the call.

Real behavior proof (required for external PRs)

N/A. Maintainer-authored internal refactor surface; no end-user reply path is migrated in this PR.

Root Cause (if applicable)

• Root cause: startup already had useful plugin/provider/channel/runtime facts, but later code had no stable loaded-runtime metadata surface to read them from, so hot consumers kept pressure to rediscover those facts through broad loaders.
• Missing detection / guardrail: registry state was tracked mostly as active/channel/http-route compatibility state, not as an explicit Gateway runtime surface for prepared selected-provider lookup.
• Contributing context: broad compatibility fallback behavior is still necessary for setup, admin, standalone, and unmigrated callers, so this PR adds a canonical loaded-runtime surface before migrating consumers.

Regression Test Plan (if applicable)

• Coverage level that should have caught this:
  • Unit test
  • Seam / integration test
  • End-to-end test
  • Existing coverage already sufficient
• Target tests or files:
  • src/plugins/runtime.channel-pin.test.ts
  • src/plugins/channel-plugin-ids.test.ts
  • src/plugins/web-provider-runtime-shared.test.ts
  • src/plugins/agent-tool-result-middleware-loader.test.ts
  • src/gateway/server-startup-post-attach.test.ts
  • src/agents/runtime-plugins.test.ts
• Scenario the tests should lock in: Gateway startup preserves loaded runtime registries, configured startup plugin ids include the owners later request paths need, provider handles can resolve from pinned Gateway runtime metadata, and middleware/public metadata lookup can use loaded runtime state before broad fallback.
• Why this is the smallest reliable guardrail: PR 2 is a startup/runtime metadata PR, so the useful boundary is the loaded registry/public metadata seam rather than a full live reply migration.
• Existing test that already covers this (if any): existing startup and runtime registry tests were extended to cover the new Gateway runtime surface.

User-visible / Behavior Changes

None expected. This PR changes internal startup/runtime metadata plumbing and preserves compatibility fallback behavior for existing callers.

Diagram (if applicable)

Before:
[Gateway startup loads plugins] -> [later code cannot read exact loaded fact] -> [consumer broad-loads registry again]

After this PR:
[Gateway startup loads plugins] -> [loaded Gateway/runtime metadata surface] -> [later PRs can pass prepared fact forward]

Security Impact (required)

• New permissions/capabilities? No
• Secrets/tokens handling changed? No
• New/changed network calls? No
• Command/tool execution surface changed? No
• Data access scope changed? No
• If any Yes, explain risk + mitigation: N/A

Repro + Verification

Environment

• OS: Linux
• Runtime/container: Node 22 / pnpm
• Model/provider: N/A
• Integration/channel (if any): N/A
• Relevant config (redacted): N/A

Steps

1. pnpm test src/plugins/runtime.channel-pin.test.ts src/plugins/channel-plugin-ids.test.ts src/plugins/bundle-mcp.test.ts src/plugins/web-provider-runtime-shared.test.ts src/plugins/agent-tool-result-middleware-loader.test.ts src/channels/plugins/bundled-root-caches.test.ts src/gateway/server-startup-post-attach.test.ts src/gateway/server-startup.test.ts src/agents/runtime-plugins.test.ts
2. pnpm build
3. git diff --check origin/main...HEAD

Expected

• Focused runtime/startup metadata tests pass.
• Build passes.
• Diff hygiene is clean.

Actual

• Focused runtime/startup metadata tests passed: 4 Vitest shards in 49.57s.
• Build passed.
• git diff --check origin/main...HEAD passed.

Evidence

• Failing test/log before + passing after
• Trace/log snippets
• Screenshot/recording
• Perf numbers (if relevant)

Evidence is the local targeted test/build proof above. During extraction, the standalone branch exposed two useful guardrails: startup model prewarm must remain metadata-only, and configured model owner plugins should be included in startup metadata alongside implicit runtime owner plugins.

Human Verification (required)

• Verified scenarios: PR 2 is one commit on top of current main; file scope is startup/runtime metadata plus CHANGELOG.md; focused Gateway/plugins/channels/agents tests pass; build passes; diff hygiene is clean.
• Edge cases checked: provider handles resolve from the pinned Gateway runtime registry after active registry churn; Gateway startup model prewarm does not import PI runtime model resolution; generated Canvas bundle hash drift from build was kept out of the PR.
• What you did not verify: live Gateway reply benchmark, because this PR does not migrate the live reply path yet.

Review Conversations

• I replied to or resolved every bot review conversation I addressed in this PR.
• I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

• Backward compatible? Yes
• Config/env changes? No
• Migration needed? No
• If yes, exact upgrade steps: N/A

Risks and Mitigations

• Risk: loaded runtime metadata could be mistaken for a request-time consumer migration.
  • Mitigation: the scope is explicit: this PR exposes the loaded metadata surfaces only. Consumer migrations remain in later PRs tracked by Tracking: Prepared runtime resolution migration #77700.
• Risk: startup might accidentally import heavier provider runtime work while exposing these facts.
  • Mitigation: Gateway startup tests preserve metadata-only primary model prewarm behavior, and build/lazy-loading proof is included.
• Risk: later PRs could still miss this surface and reintroduce broad lookups.
  • Mitigation: resolveProviderRuntimePluginHandle(...) now checks gateway-runtime, and Tracking: Prepared runtime resolution migration #77700 continues to track each consumer migration surface.