[Bug]: Release wheels embed next-patch .dev0 in bundled Rust CLI while package metadata uses the release version

[ousugo]

Issue Origin

Observed and reproduced with the official published wheel and confirmed in the official release workflow logs.

Bug Description

Official OpenViking release wheels currently embed a bundled Rust ov binary whose version is the next patch .dev0, while the wheel metadata, Python package, server CLI, and /health endpoint use the correct release version.

For example, the official 0.4.16 wheel reports:

$ ov --version
openviking 0.4.17.dev0

$ python -c 'import importlib.metadata as m; print(m.version("openviking"))'
0.4.16

$ python -c 'import openviking; print(openviking.__version__)'
0.4.16

$ curl -s http://127.0.0.1:1933/health | jq -r .version
0.4.16

The wheel's own METADATA also contains:

Version: 0.4.16

This is not an old standalone CLI shadowing the Python entry point. The Python ov entry point executes the wheel-bundled binary at openviking/bin/ov, and that binary contains the incorrect version string.

Published Release Evidence

v0.4.16

Official Linux x86_64 release job:
https://github.com/volcengine/OpenViking/actions/runs/32457027399/job/96696177614

The job log records:

Resolved OpenViking version: 0.4.17.dev0

The Rust CLI is then built with:

OPENVIKING_VERSION: 0.4.17.dev0

After the Rust binary has already been copied aside, the workflow cleans the repository and reports:

Git Describe: v0.4.16-0-g499995f3
Setuptools SCM Version: 0.4.16
Build Version: 0.4.16

The resulting 0.4.16 wheel therefore packages a Rust binary compiled as 0.4.17.dev0.

v0.4.15

The previous release shows the same pattern:
https://github.com/volcengine/OpenViking/actions/runs/32123651683/job/95669361481

Resolved OpenViking version: 0.4.16.dev0
Setuptools SCM Version: 0.4.15
Build Version: 0.4.15

This makes the mismatch deterministic across consecutive releases rather than a one-off installation problem.

Root Cause

The relevant order in .github/workflows/_build.yml is effectively:

checkout release tag
→ uv sync --frozen / build the local project
→ resolve_openviking_version()
→ export OPENVIKING_VERSION
→ build and preserve the Rust CLI
→ git reset --hard / git clean
→ resolve the clean SCM version and build the Python wheel

resolve_openviking_version() uses setuptools_scm. At the pre-clean Rust CLI step it resolves the exact release tag as the next patch development version. That value is passed through crates/ov_cli/build.rs as OPENVIKING_CLI_VERSION and compiled into ov.

The later clean step restores the exact tagged version for Python wheel metadata, but it preserves the already-built Rust binary, creating two different versions inside one artifact.

This is closely related to previous build work:

• Fix/ci clean workspace #170 added clean-workspace handling specifically to avoid dirty setuptools_scm versions.
• fix(build): sync ov cli version with openviking #869 introduced the shared Python/Rust version resolver, but the Rust version is resolved before the existing clean step and no built-artifact parity test was added.
• fix(docker): resolve image version explicitly #1698 already uses the safer pattern for Docker builds: derive the release version explicitly from the tag/workflow input instead of relying on an incidental source-tree state.

There are also incidental sightings of the mismatch in #4131, #4132, and #4201, although those issues concern unrelated runtime behavior.

Expected Behavior

For an official release wheel, all version sources should match the release tag:

ov --version
== importlib.metadata.version("openviking")
== openviking.__version__
== openviking-server --version
== /health version

For v0.4.16, each should report 0.4.16.

Actual Behavior

The published wheel metadata and server report 0.4.16, while the bundled Rust CLI reports 0.4.17.dev0.

Suggested Fix

1. Pass the release version explicitly from github.event.release.tag_name (or a required reusable-workflow input), strip the leading v, and export that value as OPENVIKING_VERSION before building the Rust CLI.
2. For non-release/manual builds that still use SCM discovery, resolve only from a clean tree or clearly allow a development version.
3. Add a post-install release smoke test that fails the build unless the bundled CLI version matches the wheel metadata and Python package version.

A release-event version should not depend on whether prior dependency or native build steps left the checkout dirty.