fix(fff-mcp): compare CARGO_PKG_VERSION to stable release tag (#721)

[gustav-fff]

Closes #721

Root cause

crates/fff-mcp/src/update_check.rs:41-44 compared a 40-char git SHA prefix (FFF_GIT_HASH) against the release tag string. A commit SHA can never equal a semver tag like v0.10.1 or 0.10.2-nightly.6a239e9, so the notice fires forever. fetch_latest_tag also queried /releases?per_page=1, which includes prereleases, while install-mcp.sh:11 is pinned to a stable tag — the installer in the notice cannot silence a nightly-triggered notice.

Fix

Query /releases/latest (GitHub excludes prereleases from this endpoint) and compare CARGO_PKG_VERSION against the tag with a leading v stripped. FFF_GIT_HASH is still embedded for the --version string; only the update check stops using it.

Steps to reproduce

Setup on origin/main (pre-fix):

git checkout main
curl -fsSL https://raw.githubusercontent.com/dmtrKovalenko/fff.nvim/main/install-mcp.sh | bash

Confirm the installed binary matches the pinned stable release:

fff-mcp --version
# fff-mcp 0.10.1 (686a84959ddc72185a7cacaf00145af5ccac7a83)

Trigger the check directly (equivalent to the background thread spawn_update_check):

curl -fsSL --max-time 5 -H 'Accept: application/vnd.github.v3+json' \
  'https://api.github.com/repos/dmtrKovalenko/fff.nvim/releases?per_page=1' \
  | jq -r '.[0].tag_name'
# 0.10.2-nightly.6a239e9   (a prerelease)

Expected: no update notice, because the installed binary is on the latest stable channel and install-mcp.sh is pinned to v0.10.1.

Actual: MCP responses include:

[fff update available: `curl -fsSL https://raw.githubusercontent.com/dmtrKovalenko/fff.nvim/main/install-mcp.sh | bash`]

Re-running the installer reinstalls the same stable binary. The notice returns because "6a239e987569800c45661c6a67bc4af" (SHA prefix truncated to tag length) will never equal "0.10.2-nightly.6a239e9".

How verified

$ cargo test -p fff-mcp --bin fff-mcp update_check
running 5 tests
test update_check::tests::empty_tag_is_silent ... ok
test update_check::tests::same_version_without_v_prefix_is_silent ... ok
test update_check::tests::older_current_reports_update ... ok
test update_check::tests::nightly_tag_never_equals_stable_current ... ok
test update_check::tests::same_version_with_v_prefix_is_silent ... ok
test result: ok. 5 passed; 0 failed

Also cargo fmt -p fff-mcp and cargo clippy -p fff-mcp --bin fff-mcp -- -D warnings are clean.

Regression cases covered by tests:

• current 0.10.1 + tag v0.10.1 -> no notice
• current 0.10.1 + tag 0.10.2-nightly.6a239e9 -> notice (upgrade to whatever /releases/latest returns; nightlies excluded so this case is only synthetic — real callers get the newest stable tag)
• current 0.10.0 + tag v0.10.1 -> notice "0.10.0 -> 0.10.1"

Note: the update check now tracks the stable channel exclusively (option 1 from the issue). Nightly builds will report an update when a newer stable is out; there is currently no separate nightly channel wired through the checker. If explicit stable/nightly support is desired later, that would be a follow-up.

Automated triage via Gustav. Honk-Honk 🪿