Support custom static auth header injection for remote MCP catalog entries

[alberttwong]

Summary

Static Credentials for remote MCP servers currently support only Authorization header injection via access_token or raw_access_token. They do not support arbitrary static header injection such as x-api-key, which blocks integration with upstream MCP servers that require API keys in non-Authorization headers.

Problem

For a remote MCP catalog entry using Static Credentials, an admin can define install-time fields via userConfig, but the remote MCP client path only maps these static secrets to:

• access_token -> Authorization: Bearer <token>
• raw_access_token -> Authorization: <token>

There does not appear to be a supported way for a static remote catalog entry to say "take this credential value and send it as x-api-key".

Repro

1. Create a remote MCP catalog item with static credentials using userConfig, for example an API_KEY field.
2. Install the server and provide a valid API key.
3. Call the remote MCP server through Archestra.
4. Observe that Archestra does not send x-api-key: <value> to the upstream MCP server.

Expected behavior

A remote MCP catalog entry should be able to declare static auth/header mapping for custom headers, for example:

• x-api-key: <secret>
• other custom headers needed by upstream MCP servers

Why this matters

Many third-party APIs and MCP wrappers expect API keys in headers like x-api-key rather than Authorization. Today the workaround is to:

• modify the upstream MCP server to accept Authorization, or
• place a proxy in front of it to translate headers

Both are avoidable if the catalog/runtime supports custom static header injection directly.

Notes

The current runtime behavior appears to be in the remote MCP client path, where static secrets are translated only into Authorization headers for access_token / raw_access_token.

[alberttwong]

#3676