fix(auth): resolve az via shutil.which so azure-cli token works on Windows

[jawwad-ali]

Problem

AzureDevOpsAuth._acquire_via_az_cli() runs:

result = subprocess.run(["az", "account", "get-access-token", ...], ...)

with a bare "az". On Windows the Azure CLI is installed as az.cmd, and subprocess.run calls CreateProcess, which — unlike a shell — does not consult PATHEXT. So a bare "az" fails with WinError 2 (FileNotFoundError) even when az works fine in the user's terminal after az login. The except OSError swallows it, so auth: azure-cli silently returns no token on Windows.

(Verified on a Windows box: shutil.which("az") → ...\wbin\az.CMD, i.e. the runnable target is the .CMD shim, which the bare name never reaches.)

Fix

Resolve the executable with shutil.which("az") (which honors PATHEXT) before invoking it — exactly the fix the maintainer already applied in integrations/base.py for the same CreateProcess/.cmd problem:

az = shutil.which("az") or "az"
result = subprocess.run([az, "account", "get-access-token", ...], ...)

or "az" preserves the previous behaviour (and the existing not-installed OSError path) when az is absent. On POSIX shutil.which returns the same executable, so behaviour is unchanged there.

Verification

• New test_resolve_token_azure_cli_resolves_executable: patches shutil.which → a fake az.CMD path and asserts the resolved path is argv[0]. Fails before (no shutil import to resolve with), passes after.
• New test_resolve_token_azure_cli_falls_back_to_bare_az: shutil.which → None still yields argv[0] == "az" (fallback preserved).
• Existing azure-cli success/failure/not-installed tests unchanged: 11 passed. ruff clean.

---

AI-assisted: authored with Claude Code. I confirmed on Windows that shutil.which("az") resolves to az.CMD and mirrored the maintainer's existing integrations/base.py resolution.

[Copilot]

Pull request overview

Resolves Azure CLI authentication on Windows by locating the executable shim before invocation.

Changes:

• Resolves az through shutil.which, retaining the existing fallback.
• Adds tests for resolved and fallback executable paths.

Show a summary per file

File	Description
src/specify_cli/authentication/azure_devops.py	Resolves the Azure CLI executable before token acquisition.
tests/test_authentication.py	Tests executable resolution and fallback behavior.

Review details

Tip

Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

• Files reviewed: 2/2 changed files
• Comments generated: 0
• Review effort level: Medium

[Copilot]

Review details

• Files reviewed: 2/2 changed files
• Comments generated: 1
• Review effort level: Medium

[mnriem]

Please address Copilot feedback and resolve test & lint errors

[jawwad-ali]

Good catch — that was the macOS CI failure, fixed in 0dd35a7. The hardcoded C:\Program Files\... reads as relative under posixpath, so on Linux/macOS the production os.path.isabs() sent it down the fallback branch and argv[0] was "az".

The path is now built with the host's rules — os.path.join(os.path.abspath(os.sep), "opt", "az", "az.CMD") — with an assert os.path.isabs(...) so the intended branch is guaranteed to be the one under test (/opt/az/az.CMD on POSIX, D:\opt\az\az.CMD on Windows). The fallback test's inputs (.\az.CMD, az.cmd, ./az) are relative under both ntpath and posixpath, so those were already portable.