Fix MCP server infinite respawn loop on upgrade/install failure

[samvaity]

Problem

When the MCP server launch script (azure-sdk-mcp.ps1) fails to check for upgrades or download updates — due to GitHub API rate limiting (403), gateway timeouts (504), or network errors — it exits with a non-zero code. The MCP client (VS Code, Copilot CLI) immediately respawns the process, creating an infinite loop that can spawn hundreds of pwsh processes and choke the machine.

Additionally, when the binary is installed at ~/bin (the default) but that directory isn't on $PATH, the script doesn't find the existing binary and always attempts a fresh install.

Fix

Fall back to the existing binary when upgrade or install fails in -Run (MCP) mode:

1. Check default install directory: When Get-Command doesn't find azsdk on PATH, also check ~/bin (the default install directory from Get-CommonInstallDirectory).

2. Upgrade check failure fallback: When azsdk upgrade --check returns a non-zero exit code (rate limit, network error) but the binary already exists, log a warning and run the existing binary instead of falling through to Install-Standalone-Tool.

3. Install failure fallback: When Install-Standalone-Tool throws in MCP mode, check if an existing binary is available at the known install directory and fall back to it instead of exit 1.

Validation

• PowerShell script parses cleanly (no syntax errors)
• Non-MCP mode behavior is unchanged (still exits with error)
• When no binary exists at all, behavior is unchanged (exit 1)

Fixes #15973
Fixes #15953

[Copilot]

Pull request overview

This PR updates the MCP launch script (eng/common/mcp/azure-sdk-mcp.ps1) to prevent an infinite respawn loop when upgrade/install steps fail (e.g., GitHub rate limiting, 504s, transient network issues) by falling back to an already-installed azsdk binary when running in -Run (MCP) mode.

Changes:

• If azsdk isn’t found on PATH, also probe the default install directory (~/bin via Get-CommonInstallDirectory) for an existing binary.
• In -Run mode, if azsdk upgrade --check fails but an existing binary is present, log a warning and run the existing binary instead of attempting reinstall.
• In -Run mode, if installation throws, fall back to an existing binary in the install directory (when present) rather than exiting with code 1.

[azure-sdk-automation]

The following pipelines have been queued for testing:
java - template
java - template - tests
js - template
net - template
net - template - tests
python - template
python - template - tests
You can sign off on the approval gate to test the release stage of each pipeline.
See eng/common workflow

[azure-sdk-automation]

The following pipelines have been queued for testing:
java - template
java - template - tests
js - template
net - template
net - template - tests
python - template
python - template - tests
You can sign off on the approval gate to test the release stage of each pipeline.
See eng/common workflow