Provider: Azure returns 404 on Microsoft Foundry (Formerly Azure AI Foundry) endpoints due to legacy path routing

Before submitting your bug report

• I've tried finding an answer on the Continue docs site
• I'm not able to find an open issue that reports the same bug
• I've seen the troubleshooting guide on the Continue Docs

Relevant environment info

- OS: Windows
- Continue version: 2.0.0
- IDE version: VSCode
- Model: gpt-5.3-codex
- config:
name: Main Config
version: 1.0.0
schema: v1
models:
  - name: gpt-5.3-codex
    provider: azure
    model: gpt-5.3-codex
    apiKey: YOUR_API_KEY
    apiBase: https://<your-resource>.services.ai.azure.com/openai/v1/responses

Description

When using provider: azure with an Azure AI Foundry (Model-as-a-Service / Serverless) endpoint, Continue attempts to send requests using legacy Azure OpenAI path structures (e.g., appending /openai/deployments/...). This causes a 404 Resource Not Found error because Azure AI Foundry uses a newer, OpenAI-compatible routing path (/openai/v1/...).

Workaround: Changing the provider to openai while keeping the same Azure AI Foundry apiBase successfully resolves the issue, proving that the endpoint itself works, but Continue's internal azure provider driver forces an incompatible URL structure.

The azure provider should gracefully support both modern (OpenAI-compatible) and legacy endpoint configurations.

Possible Solutions / Approaches:

1. Auto-detection / Regex: Dynamically parse or evaluate the apiBase structure to determine whether to use modern or legacy paths.
2. Configuration Property: Introduce an explicit option (e.g., apiType or routing mode flag) to let users toggle between legacy deployment-based paths and modern serverless/managed compute paths.

To reproduce

1. Create a model deployment in Azure AI Foundry (which uses the services.ai.azure.com domain).
2. Configure Continue with provider: azure and point the apiBase to the Azure AI Foundry endpoint.
3. Attempt to prompt or chat with the model.
4. Observe the 404 error in the error output.

Log output

Start at the Azure provider driver and its request URL construction, using the reported apiBase and the reproduction steps as the entry point. Compare its routing with the working openai provider behavior. Done means Azure configurations using modern /openai/v1/ paths work without breaking legacy deployment-based endpoints.