[ty] Fix site-package error when multiple versions of pythons are installed in system path

[cheparity]

Summary

Fix astral-sh/ty#3424

When --python /opt/bin/python3.14 is passed, the sys.prefix is derived as /opt (grandparent of the executable), but the Python version (3.14) embedded in the filename was discarded. For system installations without a pyvenv.cfg, SystemEnvironment had no way to know the version, so site_packages_directories_from_sys_prefix scanned all python3.* directories under the lib dir, picking up site-packages from unrelated Python versions.

Fix by extracting the Python version from the executable path before it's resolved to sys.prefix, and threading it through SystemEnvironment into the site-packages discovery, so it can target the exact version directory via probe_package_dirs instead of scanning all versions.

A noticeable change is that

pub struct SystemEnvironment {
    root_path: SysPrefixPath,
    python_version: Option<PythonVersion>, //! newly added
}

the struct was changed to convey version info. May it cause potential influence to other modules?

CC @MichaReiser . Thanks for reviewing.

Test Plan

A new unit test uses_correct_site_packages_when_python_executable_path_has_version was added by simulating the issue's system path.

[astral-sh-bot]

Typing conformance results

No changes detected ✅

Current numbers

The percentage of diagnostics emitted that were expected errors held steady at 92.23%. The percentage of expected errors that received a diagnostic held steady at 87.42%. The number of fully passing files held steady at 92/134.

[astral-sh-bot]

Memory usage report

Memory usage unchanged ✅

[astral-sh-bot]

ecosystem-analyzer results

No diagnostic changes detected ✅

Full report with detailed diff (timing results)