Connector Namespace MCP server returns 403 to Foundry OAuth passthrough (Runtime.All vs user_impersonation scope)

## Summary

A Foundry agent using **OAuth Identity Passthrough** authenticates successfully and reaches a **Connector Namespace** MCP server, but the gateway returns **HTTP 403** while enumerating tools. The same user's CLI token works against the same endpoint. Root cause appears to be the gateway requiring the legacy `user_impersonation` scope, which a v2/MSAL client (like Foundry) cannot obtain.

## Environment

- Connector gateway: `` (westcentralus)
- MCP server config: ``
- Endpoint: `https://app-06.westcentralus.logic.azure.com/api/connectorGateways//mcpServerConfigs//mcp`
- Resource (audience): `https://apihub.azure.com` (Azure API Connections app, `fe053c5f-3692-4f14-aef2-ee34fc081cae`)

## What works

- CLI: `az account get-access-token --resource https://apihub.azure.com` → MCP Inspector `tools/list` returns all tools successfully.
- That token's claims: `aud=https://apihub.azure.com`, `oid=` (has an access policy on the config), **`scp=user_impersonation`**, `ver=1.0`.

## What fails

- Foundry **OAuth Identity Passthrough** (public client app, redirect `https://global.consent.azure-apim.net/redirect/`, scope `https://apihub.azure.com/Runtime.All`) → **403 Forbidden**: "Access denied … while enumerating tools."
- Same user `oid`, same `aud`, same authorized access policy on the mcpserverconfig. The **only** differing claim is **`scp=Runtime.All`** (v2 flow) vs `user_impersonation` (v1 flow).
- Also tried scope `https://apihub.azure.com/.default` → same 403.

## Why this can't be fixed client-side

- `Azure API Connections` (the resource for `apihub.azure.com`) exposes **only** `Runtime.All` as a delegated scope.
- `user_impersonation` is only produced by the **legacy v1 `--resource` flow**. Requesting it explicitly as a v2 scope fails: `az account get-access-token --scope https://apihub.azure.com/Runtime.All` returns `AADSTS65002` (first-party CLI not preauthorized for that scope).
- A v2/MSAL client (Foundry passthrough) can therefore **only ever obtain `Runtime.All`**, never `user_impersonation`.

## Ask

1. Does the MCP/gateway token validation require the legacy `user_impersonation` scope? If so, please **also accept `Runtime.All`** — the only delegated scope the `apihub.azure.com` resource exposes, and all a v2/MSAL client can request.
2. If there is a different supported way for a v2/MSAL client (e.g., Foundry OAuth Identity Passthrough) to obtain a token the gateway accepts, please document it.

## Note

I could not decode Foundry's exact outbound token to 100%-confirm `scp` is the rejected claim — tenant Conditional Access blocks the device-code flow used to reproduce it. However, `aud`/`oid` are confirmed valid, and `appid` is ruled out (the CLI's `appid` is not in any access policy yet its token works), leaving `scp` as the only differentiator.

Start with the Connector Namespace MCP gateway's token-validation path and reproduce tools/list using the documented CLI and Foundry OAuth flows. Compare the accepted claims and scope checks for user_impersonation and Runtime.All; done means the v2 token is accepted or the supported v2/MSAL configuration is documented.

Written by the indexing model from the issue text.