fix(shim): discover install-time shims from disk, not static provider

[CalvinAllen]

Summary

• Install previously copied shim files and shim-map cache entries from the provider's static Shims() declaration regardless of whether the matching executables existed on disk. On Windows that produced phantom python3 and pip shims for python-build-standalone — which ships only python.exe / pythonw.exe in the root and an empty Scripts/.empty placeholder — leaving users with shims that errored at invocation time with "secondary executable not found: pip" even though install reported success.
• reshim already handled this correctly by registering only executables it discovered on disk, so install and reshim disagreed about which shims existed. After a fresh install of Python 3.14.2 on Windows, running dtvem reshim would drop the phantom entries and dtvem doctor would flag the cache as out of sync.
• Factor the per-version disk scan out of RehashWithCallback into a new exported helper, shim.DiscoverShimsForVersion. Route node, python, and ruby provider createShims() through it so install registers exactly the executables that exist in bin/, root/, and Scripts/. After this change the post-install state matches the post-reshim state by construction.
• pythonw is now picked up on Windows; pip / pip3 / pip3.X appear when ensurepip succeeds and are silently omitted when it fails (no more shims promising commands that don't exist).
• No new error paths: if the install dir contains no executables createShims returns an explicit error, surfacing what would previously have been a silent "install succeeded but nothing was shimmed" outcome.

Resolves #269

What didn't change

• Provider.Shims() is still used by mapShimToRuntime as a fallback when the cache lookup misses (e.g., first invocation of pip before the cache is populated). The static list remains useful as a declaration of expected shims for prefix-matching; it's just no longer the source of truth at install time.
• The user-visible install spinner sequence is unchanged. installPipIfNeeded still runs python -m ensurepip --default-pip --upgrade and reports "pip configured successfully" / "Failed to configure pip" the same way. The only difference is that on failure, no broken pip / pip3 shims are left behind.

Test plan

• ./rnr check — gofmt clean, golangci-lint reports 0 issues, full test suite passes on Windows
• 6 new unit tests in internal/shim/manager_test.go:
  • empty dir → empty result
  • missing dir → empty result (no panic / no error)
  • Unix bin/ contents discovered
  • Windows python-build-standalone layout before ensurepip → [python, pythonw] only; .empty placeholder ignored
  • Windows python-build-standalone layout after ensurepip → [pip, pip3, pip3.14, python, pythonw]
  • duplicate names across root/ and Scripts/ deduped
• CI passes on Windows / macOS / Linux