python: remove implicit PATH fallback for CLI executable resolution

[SteveSandersonMS]

Summary

Part of #2524 (Consolidate runtime discovery, acquisition, and embedding). Removes the Python SDK's implicit fallback to PATH-based executable resolution, satisfying the required outcome:

Python does not implicitly select an executable through PATH; it uses the SDK-managed runtime or an explicitly configured path.

Background

Commit 05dd60e (#793) added a shutil.which(cli_path) fallback in CopilotClient._start_cli_server that runs whenever the resolved cli_path does not exist as a file. This let the SDK silently pick up an arbitrary same-named executable from the host PATH instead of using the runtime the SDK actually resolved (explicit path > COPILOT_CLI_PATH > SDK-managed download, see _resolve_runtime_entrypoint). #1934 flagged this explicitly for removal, and #2522/#2524 carry that forward.

I confirmed on latest main (0921029) and on the in-flight roji-unify-runtime-artifacts branch (#2505) that this fallback is unchanged in both — #2505 only changes how the runtime is downloaded/verified from GitHub Releases for Python/.NET/Go/Java, not this PATH-search behavior at process start, so this is not duplicating that work.

What changed

• python/copilot/client.py: _start_cli_server now raises a clear RuntimeError when the resolved cli_path doesn't exist, instead of falling back to shutil.which. Removed the now-unused shutil import.
• python/test_client.py: added a regression test that plants a same-named decoy executable on PATH and asserts it is never used when the configured path is missing.

Not in scope here (tracked separately on #2524)

• Runtime acquisition from GitHub Releases for Python/.NET/Go/Java (in-flight in Use GitHub Releases for SDK runtime artifacts #2505; already release-backed for Java/Rust per Use Copilot CLI releases for Node runtime #2463).
• Rust (bundled-in-process Cargo feature) and Go (copilot_inprocess build tag) compile-time in-process embedding choices — see my findings comment on [v2] Consolidate runtime discovery, acquisition, and embedding #2524 for why I'm not changing these here and what maintainer input I'm requesting.

Validation

• ruff check / ruff format --check on changed files: pass.
• ty check on copilot/client.py: pass.
• pytest python/test_client.py python/test_cli_download.py: same 79 pre-existing environment-only failures as unmodified main (fake local CLI binary used for offline testing has no real e2e semantics); all path-resolution tests, including the new regression test, pass with zero new failures.

Closes #2524 once merged (remaining #2524 items tracked in the follow-up comment on that issue).

[github-actions]

Cross-SDK Consistency Review

This PR removes a shutil.which() fallback in the Python SDK's _start_cli_server, so that a missing resolved CLI path now raises RuntimeError immediately instead of silently falling back to searching PATH for a same-named executable (addressing #2524).

Checked for the same pattern in other SDKs:

• Node.js (nodejs/src/client.ts): only checks existsSync(this.resolvedCliPath) and throws if missing — no PATH-search fallback.
• .NET (dotnet/src/Client.cs): resolves the CLI via bundled runtime paths and File.Exists checks — no PATH-search fallback.
• Go, Java, Rust: no LookPath/which-style fallback found anywhere in their client startup code.

None of the other five SDKs implement (or ever implemented) the vulnerable PATH-search fallback that this PR removes from Python. This change simply brings Python's behavior in line with the stricter, already-consistent behavior of the other SDKs — no other SDK needs a corresponding update.

✅ No cross-SDK consistency issues found.

Generated by SDK Consistency Review Agent for #2528 · copilot · sonnet50 · 25 AIC · ⌖ 11.9 AIC · ⊞ 9.7K · ◷