Report the build commit in avocado --version

[jetm]

Problem

avocado --version reports only avocado 1.0.0-rc.1, which does not identify which build a user is running. Release candidates move faster than the version number, so one string covers many different binaries and a bug report cannot be tied to a commit.

build.rs already computed a short SHA into AVOCADO_CLI_VERSION, but nothing consumed it: the CLI declared a bare #[command(version)], which clap fills from CARGO_PKG_VERSION.

Solution

Report the commit in rustc's shape:

avocado 1.0.0-rc.1 (e566baa 2026-07-31)

Keeping the version in its own field leaves it a bare semver, so version comparisons need no special handling for an appended commit. The date is the commit date, not the build date, so rebuilding the same commit yields the same string.

This does move the version out of the last field, which two consumers were reading:

• utils::remote::check_cli_version (this repo) — fixed here.
• avocado-desktop's parse_cli_version — fixed in avocado-linux/avocado-desktop#73. That one accepts both the old and new shapes, so it is safe to merge first and is correct against today's released CLI too.

Key changes

• main.rs: #[command(version = env!("AVOCADO_CLI_VERSION"))], so the value build.rs computes actually reaches --version.
• build.rs emits <version> (<short-sha> <commit-date>), and is hardened: it unwrapped the git invocation, so building outside a checkout (source tarball, vendored crate) aborted the build instead of falling back to the bare version; it never trimmed the trailing newline off rev-parse, which would have put a line break inside the version string; and it declared no rerun-if-changed, so cargo cached the script output and kept reporting a stale commit. The rerun hint follows the branch ref, not HEAD alone, because HEAD is a symref whose contents do not change on commit.
• check_cli_version reads the version field via a parse_reported_version helper instead of split_whitespace().last(), which now yields the commit date. This matters beyond cosmetics: an unparseable version makes that check fail open and silently accept a remote running an older CLI. The helper still tolerates a bare version from an older remote.
• tests/version.rs: the version field is a bare semver equal to the crate version, and the line carries the current commit and date (skips outside a git checkout).
• Unit tests for parse_reported_version across the new shape, the old bare shape, and a version with no prefix.

Reviewer notes

• Verified end to end: prints avocado 1.0.0-rc.1 (e566baa 2026-07-31); committing without touching build.rs rebuilds and reports the new commit, which is the check that the stale-commit fix actually works.
• cargo fmt, cargo clippy --all-targets --all-features -- -D warnings, and the full cargo test suite are clean.
• No CI change needed: actions/checkout@v5 leaves .git present, so release and PR builds resolve a commit; cross musl builds and the Windows cargo check fall back to the bare version if git is unavailable rather than failing.
• env!("TARGET") from the same build script is unchanged (still used by avocado upgrade).
• A .dirty marker for uncommitted builds was deliberately left out to keep this focused; easy follow-up if wanted.

[jetm]

Companion PR: avocado-linux/avocado-desktop#73 fixes the other consumer of this line (parse_cli_version), which otherwise reads the commit date as the installed CLI version.

Suggested order: merge the desktop one first. It accepts both the old bare avocado 0.40.0 and the new avocado 1.0.0-rc.1 (abc1234 2026-03-05) shapes, so it is correct against today's released CLI too, and landing it first avoids a window where the Updates pane misreports for anyone running a CLI built from this branch.