Windows: Copilot integration hardcodes `copilot.cmd`, breaking installs that ship `copilot.exe`

src/specify_cli/integrations/copilot/init.py で _copilot_executable() と _resolve_executable() を読み始め、その後 tests/integrations/test_extra_args.py にある既存のカバレッジを実行します。copilot.exe だけを含む Windows PATH のリグレッションカバレッジを追加し、コマンドディスパッチが copilot.cmd を前提とするのではなく、インストール済みの実行可能ファイルを解決できれば issue は完了とみなします。

Bug Description

CopilotIntegration._resolve_executable() falls back to a hardcoded, platform-guessed executable name on Windows (copilot.cmd) instead of detecting what's actually installed. When the GitHub Copilot CLI is installed in a way that produces copilot.exe rather than an npm-style .cmd shim, workflow/command dispatch to the copilot integration fails outright on Windows, because Spec Kit never looks for the actual executable on PATH.

Steps to Reproduce

1. On Windows, install the Copilot CLI via a distribution that produces copilot.exe on PATH (not an npm global-install shim producing copilot.cmd).
2. Run any Spec Kit workflow/command step with integration: copilot (e.g. specify workflow run ...).
3. Dispatch fails because Specify attempts to invoke copilot.cmd, which does not exist, instead of the copilot.exe that is actually on PATH.

Expected Behavior

Spec Kit should detect the actual Copilot CLI executable available on the user's PATH on Windows, rather than assuming a single fixed name.

Actual Behavior

Specify attempts to invoke copilot.cmd even when only copilot.exe is installed on PATH, so workflow/command dispatch fails.

Specify CLI Version

1.0.7 (as encountered; likely affects other versions using the same _copilot_executable() logic)

AI Agent

GitHub Copilot

Operating System

Windows (version not specified)

Python Version

N/A (not provided)

Error Logs

N/A (no specific error output provided)

Additional Context

Where: src/specify_cli/integrations/copilot/__init__.py

def _copilot_executable() -> str:
    """Return the executable name for Copilot CLI on this platform.

    On Windows, subprocess invocation is reliable with `copilot.cmd`.
    """
    if os.name == "nt":
        return "copilot.cmd"
    return "copilot"

def _resolve_executable(self) -> str:
    """Return the Copilot CLI executable, respecting the env-var override.

    Checks ``SPECKIT_INTEGRATION_COPILOT_EXECUTABLE`` first.  Falls
    back to the platform-specific default from ``_copilot_executable()``
    (``copilot.cmd`` on Windows, ``copilot`` elsewhere) so that
    existing behaviour is preserved when the env var is unset.
    """
    env_name = "SPECKIT_INTEGRATION_COPILOT_EXECUTABLE"
    override = os.environ.get(env_name, "").strip()
    return override if override else _copilot_executable()

Why this likely wasn't caught earlier:

• Workflow command-step dispatch is a newer code path. Most integration scaffolding (init, command registration, writing .github//.claude/ files) never has to spawn the Copilot CLI as a subprocess. _resolve_executable()/build_exec_args() only matter once something actually shells out to copilot, which is essentially exclusive to specify workflow run command steps — so long-time Spec Kit + Copilot users could easily never exercise this path.
• The hardcoded copilot.cmd guess suggests testing only covered an npm global install (npm install -g @github/copilot or similar), which npm wraps in a .cmd shim on Windows by convention. Installing the Copilot CLI via a different channel (standalone installer, winget, scoop, a signed native binary, etc.) produces a real copilot.exe on PATH instead, and hits this bug immediately and reliably. If most Windows testers install via npm, this simply never surfaces for them.
• The SPECKIT_INTEGRATION_COPILOT_EXECUTABLE override itself appears recently added (per its own docstring: "so that existing behaviour is preserved when the env var is unset"), suggesting this is a known, actively-being-patched rough edge rather than a long-stable path.

Net: this only surfaces at the intersection of (a) workflows that dispatch to Copilot as a subprocess, (b) Windows, and (c) a non-npm Copilot CLI install — a narrow combination most contributors/testers may not sit in.

Suggested fix:

def _copilot_executable() -> str:
    """Return the executable name for Copilot CLI on this platform."""
    if os.name != "nt":
        return "copilot"

    for candidate in ("copilot.exe", "copilot.cmd", "copilot"):
        if shutil.which(candidate):
            return candidate

    # Nothing found on PATH — keep the historical default so the
    # resulting "command not found" error still references the
    # previously expected name.
    return "copilot.cmd"

shutil is already imported in this module, so this requires no new dependency. Suggest adding a regression test alongside the existing _resolve_executable/build_exec_args coverage in tests/integrations/test_extra_args.py, mocking shutil.which to simulate a Windows install exposing only copilot.exe.

Workaround: SPECKIT_INTEGRATION_COPILOT_EXECUTABLE already exists and can be set to copilot.exe explicitly, scoped to the invoking process, until this is fixed upstream.

AI Disclosure

GitHub Copilot (GPT-6 Sol) organized the user-provided issue text into the repository's bug-report template and filed it. Human-directed; no independent reproduction or code changes. Reasoning-effort setting not provided.