fix: don't mistake Windows' Python stub for a real interpreter

[susmit-holbox]

Summary

• Windows ships python.exe/python3.exe "App Execution Alias" stubs in WindowsApps that sit on PATH by default even with no real Python installed. They're real files/processes, just useless ones — running one just prints "Python was not found; run without arguments to install from the Microsoft Store...".
• install.ps1's Install-Ddgs and tools.rs's execute_web_search both treated the stub as a real interpreter, so the existing embedded-Python fallback (Install-EmbeddedPython/embedded_python_path) never triggered — ddgs install/usage failed with a confusing "Python not found"-shaped error instead of falling back to the self-contained Python that's already downloaded for exactly this case.
• install.ps1 now rejects a resolved python/python3 path under WindowsApps (Test-IsAppExecutionAliasStub) and falls through to Install-EmbeddedPython, same as if nothing were found.
• tools.rs now recognizes the stub's distinctive output after a successful-but-useless spawn (looks_like_windows_app_execution_alias_stub) and retries against the embedded interpreter, the same way it already does for a NotFound spawn error. If there's no embedded Python either, it now returns a message that names the actual problem (a Store stub) instead of the generic "could not run" text.
• No new persistent state: detection is re-done on every web_search call and on every install run, so a real Python installed later is picked up automatically.

Test plan

• cargo test --bin boxcode — 360 passed, including two new tests (web_search_falls_back_to_the_embedded_python_when_configured_one_is_the_windows_stub, a_windows_stub_with_no_embedded_fallback_is_explained_clearly)
• tests/install_ps1_test.ps1 run against a locally-downloaded pwsh 7.6.4 — 27/27 passed, including new Test-IsAppExecutionAliasStub cases
• Manual verification on a real Windows machine with no Python installed (not available in this environment)