fix(host-core): detect MSIX Store pwsh app-execution aliases

[Frank-zhu0404]

Summary

• PowerShell 7 installed via winget's default MSIX / Microsoft Store layout never appeared as windows-pwsh, because PATH lands on a zero-byte Store app-execution alias (IO_REPARSE_TAG_APPEXECLINK under WindowsApps).
• Windows PATH probing used Path::is_file() / CreateFileW, which returns ERROR_CANT_ACCESS_FILE (1920) on those aliases, so probe 2 discarded a working pwsh.exe.
• Probe via GetFileAttributesExW and accept existing non-directory .exe paths, including zero-size reparse aliases. Do not use size > 0 as a validity check.
• Spec + E2E scenario docs updated for the Store-alias PATH probe.

Fixes #607

Test plan

• cargo fmt -p host-core -- --check
• cargo test -p host-core --locked shell:: — 12 passed (includes Store alias attrs 0x420 / tag 0x8000001B, normal file, directory, missing path)
• Codex gpt-5.6-sol max review — VERDICT=PASS
• Live Windows: MSIX/winget PowerShell 7 with no %ProgramFiles%\PowerShell\7 — Settings → command shell shows PowerShell 7; Bash launches it via the WindowsApps alias
• MSI / classic install still resolves %ProgramFiles%\PowerShell\7\pwsh.exe (probe 1 unchanged)

Notes

• Live Store-alias execution is Windows-only and is not exercised in Linux CI; unit tests cover the Win32-attribute decision on all platforms.
• Clippy -D warnings currently fails on unrelated pre-existing useless_format in user_skills.rs (not touched here).

[vastsa]

审查结论：实现方向无原则问题，但当前验证缺 Windows 编译和真实 MSIX Store alias 运行；Linux 只覆盖属性 helper，不能证明 Win32 API 路径。请补 Windows target/实机验证后再合入。

[vastsa]

已审查实现并在 PR head 上完成 x86_64-pc-windows-gnu 的 host-core cargo check；属性测试覆盖 alias/目录/缺失路径。真实 MSIX Store alias 仍需后续 Windows 实机回归，但无原则或架构级阻塞，可合入。