[ty] Fix server version

[MichaReiser]

Summary

Closes astral-sh/ty#814

cargo-dist only sets the version of the ty crate. That means, the CARGO_PKG_VERSION is always 0.0.0 for the ty_server.

This PR works around this by adding the program_version to ruff_db which gets initialized by the ty crate (where the version is correct)
and the server can read from. This has the nice side effect that the same version can be used in the type checking panic handler (in ty_project).

An alternative would have been to pass the version to ty_server but we then couldn't use it in the catch handler in ty_project.

I made some changes to ty's build script to take the commit from the ruff repository when not built inside the ty repository.
This gives us at least some meaningful version identifier for debug builds.

Test Plan

Version in initialize response:

    "serverInfo": {
        "name": "ty",
        "version": "ruff/0.12.2+87 (426fa4bb1 2025-07-11)"
    }

Version logged during startup

2025-07-11 15:19:23.122004000 DEBUG Version: ruff/0.12.2+87 (426fa4bb1 2025-07-11)
2025-07-11 15:19:23.127378000  INFO Defaulting to python-platform `darwin`
2025-07-11 15:19:23.127599000 DEBUG Discovering virtual environment in `/Users/micha/astral/test`

Version in panic handler

error[panic]: Panicked at crates/ty_python_semantic/src/types.rs:97:5 when checking `/Users/micha/astral/test/create.py`: `Test`
info: This indicates a bug in ty.
info: If you could open an issue at https://github.com/astral-sh/ty/issues/new?title=%5Bpanic%5D, we'd be very appreciative!
info: Platform: macos aarch64
info: Args: ["target/debug/ty", "check", "../test/create.py"]
info: Version: ruff/0.12.2+88 (0f58920fc 2025-07-11)
info: run with `RUST_BACKTRACE=1` environment variable to show the full backtrace information
info: query stacktrace:
   0: check_file_impl(Id(c00))
             at crates/ty_project/src/lib.rs:474

[github-actions]

mypy_primer results

No ecosystem changes detected ✅
No memory usage changes detected ✅

[github-actions]

ruff-ecosystem results

Linter (stable)

✅ ecosystem check detected no linter changes.

Linter (preview)

✅ ecosystem check detected no linter changes.

[sharkdp]

Hmm... isn't showing the ruff version in the ty server even more confusing than showing 0.0.0? Sure, the commit hash is useful for us, but most users won't know that the ty codebase lives inside the ruff repo?

[MichaReiser]

Hmm... isn't showing the ruff version in the ty server even more confusing than showing 0.0.0? Sure, the commit hash is useful for us, but most users won't know that the ty codebase lives inside the ruff repo?

We only use the ruff commit version when you build ty from within the Ruff repository. Only developers should really be doing this. The builds that we release are all built from within the ty repository and, therefore, they use the version from the dist-workspace.toml and the commit from the ty repository.

[dhruvmanila]

cargo-dist only sets the version of the ty crate. That means, the CARGO_PKG_VERSION is always 0.0.0 for the ty_server.

Should we use the CARGO_PKG_VERSION from the ty crate? This is what the ruff_server crate does as well.

[dhruvmanila]

Why is this required? Isn't this the entrypoint for the Ruff CLI?

[MichaReiser]

This is more a precaution that we don't introduce a panic in ruff when we add a new path accessing version (Both the diagnostics and ruff analzye use the ruff_db crate).

[MichaReiser]

Should we use the CARGO_PKG_VERSION from the ty crate? This is what the ruff_server crate does as well.

I think it's important that the server version matches the output of ty version. That's why I went with using that version string instead.