feat: Make OAuth callback URIs configurable

[mxcoppell]

This pull request makes the MCP Inspector's OAuth 2.0 callback URIs configurable.

Previously, the callback URIs were hardcoded. This change allows them to be set dynamically, which is useful for environments where the Inspector is running behind a proxy or in a containerized setup with a different public-facing URL.

The implementation reads the callback URI from sessionStorage, which can be populated from environment variables on the server at startup. Specifically, the following keys are used:

• OAUTH_MCP_INSPECTOR_CALLBACK for the standard OAuth flow.
• OAUTH_MCP_INSPECTOR_DEBUG_CALLBACK for the OAuth debugging flow.

If these session storage items are not set, the Inspector falls back to the default URIs (/oauth/callback and /oauth/callback/debug).

[cliffhall]

Closing: reviewed and declined on security grounds.

Thank you for this contribution, and apologies for the long wait for a response.

This PR was included in a security review of the full v1 backlog before bulk-closing it (#1819). Unlike most of that backlog — which is closed simply because v1 is deprecated — this change was read closely and is being declined on its merits: as written, it would weaken a security control the Inspector's threat model depends on.

Specifically: redirectUrl is read from a server-influenced /config response and used to spawn additional callback listeners. (The lockfile also adds the package as a devDependency of itself.)

The Inspector's backend spawns local processes and proxies outbound requests on the developer's behalf, so it defends in layers: session-token auth, origin validation, loopback-only binding, and an SSRF block-list on the proxy. A change that removes or widens any one of those is a net loss even when it fixes a real usability problem — and several PRs in this group were framed as fixes or improvements, which is exactly why we're recording the decision explicitly rather than closing silently.

We're labeling this closed-v1-security-declined so the decision is queryable and doesn't get re-proposed against v2 later. This is not an accusation of bad intent — in most cases the security consequence was a side effect of an unrelated goal.

If the underlying need is real, we'd like to solve it in a way that preserves those controls. Please open an issue against v2 describing the problem you hit (not the patch), and we'll look at it. Note that we accept external contributions as issues rather than pull requests — see CONTRIBUTORS.md.