feat(sidecar): add provider manifest client

[KooshaPari]

Summary

Adds a reusable provider plugin manifest HTTP client for sidecars and backend adapters.

What changed

• Adds open-sse/config/providerPluginManifestClient.ts with URL resolution and schemaVersion 1 fetch validation.
• Supports OMNIROUTE_PROVIDER_MANIFEST_URL, explicit manifest URL, explicit OmniRoute base URL, and local API fallback.
• Adds node:test coverage for URL precedence, fetch headers, failed HTTP responses, and malformed manifest responses.
• Documents the client as the supported sidecar consumption boundary.

Why

Bifrost, CLIProxyAPI, and future native sidecars should consume provider metadata through a stable HTTP manifest contract instead of importing TypeScript provider registry internals. This is an incremental step toward moving provider execution behind a Go/native sidecar while preserving the current TypeScript backend and fallback behavior.

Depends on #6001 for the GET /api/v1/provider-plugin-manifest endpoint.

Validation

• node --import file:///C:/Users/koosh/omniroute-pr-sidecar-manifest-header/node_modules/tsx/dist/loader.mjs --test --test-force-exit tests/unit/provider-plugin-manifest-client.test.ts tests/unit/api/v1/provider-plugin-manifest-route.test.ts tests/unit/provider-plugin-manifest.test.ts
• npm run check:doc-links
• git diff --check

[gemini-code-assist]

Warning

You have reached your daily quota limit. Please wait up to 24 hours and I will start processing your requests again!

[KooshaPari]

Superseded by replay PR #6083 on release/v3.8.44. Closing this stale branch copy so review and CI continue on the live replacement.

[diegosouzapw]

Thanks @KooshaPari. The manifest-client idea is aligned with the sidecar/native-router roadmap, but this PR duplicates work already merged in #6001: on release/v3.8.44 we already have providerPluginManifest.ts, providerPluginManifestRegistry.ts, providerPluginManifestUrl.ts, and GET /api/v1/provider-plugin-manifest. This PR re-adds route.ts as a new file and re-declares resolveProviderPluginManifestUrl/PROVIDER_PLUGIN_MANIFEST_PATH (collision), plus it drags in unrelated churn (stryker.conf.json, should-promote-latest.sh, a translator-test swap). Could you re-cut cleanly off the current tip, keep only the genuinely new client functions (fetchProviderPluginManifest* + getProviderPluginManifestEntryForModelFromManifest) and their tests, reuse the existing providerPluginManifestUrl.ts instead of re-declaring it, and drop route.ts + the foreign churn? Then it's a clean, small addition. 🙏

[diegosouzapw]

🔀 Cycle moved: base retargeted to release/v3.8.46 — release/v3.8.45 is frozen for the release in progress (#6313). No action needed.

[diegosouzapw]

Thanks for this — a couple of things before it's mergeable. First, providerPluginManifestClient.ts doesn't have any caller yet in the codebase (external sidecars like Bifrost/CLIProxyAPI would hit the HTTP endpoint directly, not import a TS module), so right now it's scaffolding for the #6044 migration plan rather than something in active use — let's track it there instead of merging speculatively. Second, this diff also carries unrelated changes to CoolingConnectionsPanel.tsx (import source + component swap), HomePageClient.tsx, a DAST test, and the complexity baseline that have nothing to do with the sidecar manifest client — please rebase and drop those so the PR stays scoped to its stated purpose. Closing for now — happy to revisit once #6044 is agreed and this has a real consumer; feel free to re-open a focused version referencing that plan.