feat: add Azure OpenAI Service backend

[najamulsaqib]

Adds full support for Azure OpenAI as a new LLM backend alongside the existing OpenAI, Anthropic, Gemini, Kimi, DeepSeek, Bedrock, and Ollama backends.

• _call_azure() — dedicated Azure dispatch using AzureOpenAI SDK client (requires azure_endpoint + api_version, distinct from the shared _call_openai_compat() path)
• BACKENDS["azure"] — config entry with env-driven deployment name, GPT-4o pricing defaults, and api_version fallback
• detect_backend() — auto-detects Azure when both AZURE_OPENAI_API_KEY and AZURE_OPENAI_ENDPOINT are set
• extract_files_direct() and _call_llm() — both dispatch sites updated with Azure branches
• README — documents env vars, optional extras, privacy/data-residency note, and CLI cheat-sheet example

[safishamsi]

Thanks @najamulsaqib - this is a clean addition that fits the backend architecture well. Verified the design: the base_url-less azure entry is safe (Azure has its own early-return dispatch before any base_url fallback in both call paths - no KeyError in estimate_cost, the custom-provider loop, or _call_openai_compat), detect_backend correctly requires both env vars, deployment-name semantics are right, and no secrets leak. A few things before merge:

Must-fix

max_tokens → max_completion_tokens in both Azure call sites. AzureOpenAI is OpenAI-compatible, and the rest of that path uses max_completion_tokens (see _call_openai_compat and the max_completion_tokens config key). max_tokens is the deprecated param - it works for gpt-4o today, but 400s on any o-series / reasoning deployment, which is a common Azure setup. Please switch both _call_azure and the _call_llm azure branch.

Should-fix

• Add a test. There's an established pattern (tests/test_llm_backends.py, test_provider_registry.py, test_ollama.py, test_claude_cli_backend.py). Minimal coverage, mocking openai.AzureOpenAI: (a) _call_azure builds the client with azure_endpoint + api_version and parses a canned response; (b) detect_backend() returns "azure" only when both AZURE_OPENAI_API_KEY and AZURE_OPENAI_ENDPOINT are set (key alone must not select it); (c) iterating BACKENDS (e.g. estimate_cost) raises no KeyError for the base_url-less azure entry.
• Duplication drift: the _call_llm azure branch re-implements the client inline and drops the GRAPHIFY_API_TIMEOUT handling that _call_azure has. Please factor out a small _azure_client(api_key, endpoint) helper (api_version + timeout) so the two paths can't diverge.

Nice-to-have

• A one-line comment on the config noting azure intentionally omits base_url (so a future refactor doesn't route it through _call_openai_compat), and that cost is fixed gpt-4o pricing (mis-estimates for non-gpt-4o deployments).

The max_completion_tokens change is the only blocker; the test + helper would make it solid. Thanks again!

[safishamsi]

Thanks @najamulsaqib — this addresses everything cleanly. Verified on current v8:

• max_completion_tokens is now used in both Azure call sites (the deprecated max_tokens is gone from the actual create() call) — and there's a test asserting exactly that (max_completion_tokens present, max_tokens absent in the create kwargs).
• The shared _azure_client helper removes the duplication, so the api_version/endpoint/timeout can't drift between the two paths.
• The base_url-less azure entry is safe (verified earlier — azure has its own dispatch, never hits the openai-compat base_url fallback).
• tests/test_llm_backends.py: 32 passed; full suite green (1521 passed).

Good to merge. Nice work.

[safishamsi]

Landed in 7467c1b.

What it adds: Azure OpenAI Service as a new LLM backend (--backend azure). Uses AzureOpenAI from the existing openai package — no new dependency. Auto-detects when both AZURE_OPENAI_API_KEY and AZURE_OPENAI_ENDPOINT are set. Uses max_completion_tokens (not deprecated max_tokens). Priority in auto-detection: after deepseek, before bedrock.

4 tests pass. 1910 passed, 0 failures.