[BUG] Foundry helper-script credential kind hardcodes .services.ai.azure.com, fails with misleading 401 when resource is private-endpoint-only

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet (related but distinct: #66896, #67179, #64766)
• [x] This is a single bug report
• [x] I am using the latest version of Claude Desktop

What's Wrong?

When configuring "Configure third-party inference → Foundry" with Credential kind = Helper script, Claude Desktop constructs the inference request against:

https://<resource-name>.services.ai.azure.com/anthropic/v1/messages/...

This fails with:

{"error":{"code":"401","message":"Access denied due to invalid subscription key or wrong API endpoint. Make sure to provide a valid key for an active subscription and use a correct regional API endpoint for your resource."}}

The same credential (an Entra ID access token, scope https://ai.azure.com/.default, obtained non-interactively via az account get-access-token) works perfectly when sent to the same underlying Foundry resource via its other valid hostname:

https://<resource-name>.cognitiveservices.azure.com/anthropic/v1/messages/...

→ 200 OK

Root Cause

Our Foundry resource has public network access disabled and is only reachable through a private endpoint. In our environment, private DNS resolution exists for <resource-name>.cognitiveservices.azure.com (resolves to a private/internal IP), but there is no private-endpoint DNS coverage for the <resource-name>.services.ai.azure.com alias, so it falls through to the public internet path. Hitting that public path directly (same valid token) returns:

{"error":{"code":"403","message":"Public access is disabled. Please configure private endpoint."}}

Claude Desktop surfaces this as a generic 401 "invalid subscription key" message, which is misleading — the credential is valid; the request is landing on a network path the resource's firewall rejects.

Evidence the credential/helper is not the problem

• Added temporary diagnostic logging (metadata only — timestamps, token length, SHA-256 prefix, never the raw token) directly into our helper script.
• Across multiple fresh conversations/retries, every single helper invocation returned a valid, correctly-scoped, non-expired token.
• Independently verified that exact token authenticates successfully (200 OK) against the resource's .cognitiveservices.azure.com hostname, including with the required anthropic-version header.
• The only variable that changes success vs. failure is which hostname is used to reach the same resource — confirming this is a Desktop-side endpoint-construction issue, not an auth issue.

What Should Happen

One or more of:

1. Allow overriding the constructed endpoint (e.g., a full base-URL field, or a way to select .cognitiveservices.azure.com vs .services.ai.azure.com) for the Helper script credential kind, rather than only accepting a bare "resource name."
2. Surface the actual upstream HTTP status/response (e.g., the 403 "Public access is disabled" body) instead of a generic 401, so private-endpoint-only setups are diagnosable.
3. If technically feasible, fall back to .cognitiveservices.azure.com when .services.ai.azure.com isn't reachable.

Related Issues

• #66896 (Desktop probing wrong path for Foundry helper-script credential; reporter also independently verified their helper token was valid)
• #67179 (Desktop's Foundry .services.ai.azure.com construction rejected during validation despite healthy deployment)
• #64766 (Foundry model probe issues causing false failures despite working inference)

Environment

• Claude Desktop (macOS), Foundry connection with Credential kind = Helper script
• Azure AI Foundry resource with public network access disabled (private-endpoint only)