### Description `IntegrationBase.resolve_python_interpreter` in `src/specify_cli/integrations/base.py` selects `python3`/`python` by existence on `PATH` (`shutil.which`). On a stock Windows machine `python3` resolves to the Microsoft Store App Execution Alias stub: it exists on `PATH`, prints an installer hint, and exits non-zero. The resolver returns `"python3"` anyway, so every `{SCRIPT}` invocation generated for the `py` script type is broken (`Python was not found; run without arguments to install from the Microsoft Store`). This is the CLI sibling of #3304 (assessed valid, severity medium). The sh-script variants of the same existence-vs-runtime defect were fixed in #3312 and #3320; the Python resolver still has it. The irony: `sys.executable` is guaranteed to work here (the CLI itself runs on it) and the resolver prefers the dead stub over it. ### Reproduction On Windows 11 with Git for Windows and no real Python on `PATH` (the default `WindowsApps\python3.exe` stub present): ``` specify init target --integration cursor --script py --ignore-agent-tools ``` Generated command files contain `python3 .specify/scripts/python/...`, which fails at runtime with the Store installer hint. The same machine state is the one documented in #3304. ### Expected behavior The resolver skips interpreters that do not actually run and falls back to `sys.executable`, which is always live. ### Proposed fix On Windows only, verify the found interpreter with a `[path, "-c", ""]` run before accepting it, mirroring the parse-success-not-availability approach of #3312/#3320. POSIX keeps the plain existence check (no App Execution Alias there, no extra subprocess). I have a patch with regression tests ready and will open a PR.