fix(setup): detect KiCAD on any drive and pin bundled Python for v10

[LiJoeAllen]

Fixes two issues with the Windows setup scripts for KiCAD 10:

1. KiCAD detection no longer assumes C: drive. All-users installs can land on any drive; detection now queries registry uninstall keys (InstallLocation/DisplayIcon) and KICAD*_* environment variables before falling back to the standard paths.

2. KiCAD 10 must use the bundled python from its install directory. Generated MCP configs now set KICAD_PYTHON to the detected bin\python.exe, and site-packages falls back to bin\Lib\site-packages when lib\python3\dist-packages is absent (the KiCad 10 layout).

Verified on a machine with KiCAD 10.0 at D:\Program Files\KiCad (detected via registry, pcbnew import works).

[LiJoeAllen]

@mixelpixx

[mixelpixx]

Reviewed — the approach is sound, and most of it back-ports detection logic that setup-windows-opencode.ps1 already has (its Get-KiCadInfo at line 187 has the same dist-packages -> site-packages fallback), so the pattern is established in-repo. The registry enumeration order (HKLM, WOW6432Node, HKCU, then KICAD*_* env vars, then the Program Files list) is right. And you incidentally fixed a real latent bug: the original $possiblePaths array was missing a comma after the (x86) entry, masked by PowerShell's newline separation.

Three concrete changes:

1. DisplayIcon handling walks one level short: for a typical icon path D:...\KiCad\10.0\bin\kicad.exe, Split-Path -Parent yields ...\10.0\bin, and Get-KiCadInfo then probes ...\10.0\bin\bin\python.exe and misses. Walk up once more when the leaf is 'bin'.
2. $script:KnownVersions is assigned inside Find-KiCAD but consumed by Get-KiCadInfo defined above it — works because PowerShell resolves at call time, but hoist it to a script-scope constant so the coupling is visible.
3. The new setup-windows.ps1 Get-KiCadInfo omits the bin\Python.exe case-variant candidate the opencode version has. Make the two identical — or better, factor one shared helper so they cannot drift again.

Verification is necessarily anecdotal for setup scripts (CI has no D: drive); with the three items fixed I am comfortable merging on your D:-install evidence plus a re-test on a stock C: install.

[LiJoeAllen]

Thanks for the thorough review - all three items are addressed in a30be1a:

1. DisplayIcon walk-up - both scripts now walk up one level when the icon
   directory leaf is bin, so <root>\10.0\bin\kicad.exe resolves to
   <root>\10.0 instead of probing <root>\10.0\bin\bin\python.exe.
2. KnownVersions hoist - $script:KnownVersions is now a script-scope
   constant defined next to Get-KiCadInfo, not assigned inside Find-KiCAD,
   so the coupling is visible at the top of the file.
3. Probing parity - setup-windows.ps1's Get-KiCadInfo now probes both
   bin\python.exe and bin\Python.exe exactly like the opencode script, and
   each file carries a comment pointing at the sibling script so the probing
   logic cannot silently drift. I kept the two scripts standalone (each is
   distributed and run as a single file) rather than factoring a shared
   dot-sourced module; the probe logic itself is now identical.

Verification:

• Real D: install (KiCad Huaqiu 10.0; registry InstallLocation =
  D:\Program Files\KiCad\10.0; DisplayIcon = <...>\bin/kicad.exe,0):
  Find-KiCAD resolves it, and Get-KiCadInfo returns
  bin\Lib\site-packages (the KiCad 10 layout; lib\python3\dist-packages is
  absent here).
• Icon walk-up: the real ,0-suffixed icon path and a simulated layout both
  resolve to the version root and locate bin\python.exe.
• Simulated stock layout (bare root + 10.0\bin\python.exe +
  bin\Lib\site-packages): detected with the same site-packages fallback.
• Both scripts parse clean via the PowerShell AST parser (no syntax errors).

I can't spin up a real C: install on this machine, but the simulated layout
above covers the stock shape; happy to re-run on one before merging if you'd
like.