fix(backend): date-check latest stable fast path

[risu729]

Summary

• try the backend latest_stable_version fast path for latest requests even when --before or minimum_release_age is active
• when a cutoff is active, fetch remote-version metadata for the fast-path candidate and only accept it if that metadata verifies the candidate is older than the cutoff
• fall back to the chronological remote-version list when the fast-path candidate is newer than the cutoff or cannot be verified from remote-version metadata
• reuse the refreshed remote-version cache when the cutoff check already fetched metadata
• update the npm install-before e2e comments to match the dist-tag date-check fallback flow

Validation

• cargo fmt --check
• git diff --check upstream/main..HEAD
• env RUSTC_WRAPPER= cargo test latest_version_tests -- --nocapture

This PR was generated by an AI coding assistant.

[greptile-apps]

Greptile Summary

This PR changes the latest_version_with_refresh fast path so latest_stable_version is now always attempted for latest queries — even when a minimum_release_age / --before cutoff is active — and the cutoff is verified against the remote-version metadata for the fast-path candidate before accepting or falling back.

• When a cutoff is active, the candidate returned by latest_stable_version is checked against list_remote_versions_with_info; if its metadata confirms it is older than the cutoff it is returned directly, otherwise the code falls back to the full chronological list without re-fetching (cache reuse via fallback_refresh = false).
• latest_stable_candidate_allowed_by_before_date conservatively returns false for any case where the timestamp cannot be verified (version absent from list, missing created_at, or unparseable date), so the cutoff is never silently bypassed.
• The test suite is expanded with three new targeted unit tests and the e2e comment is updated to reflect the new flow.

Confidence Score: 5/5

Safe to merge — the cutoff logic is conservative and the cache reuse is correct.

The fast-path change is well-bounded: latest_stable_candidate_allowed_by_before_date returns false for every case where a release date cannot be confirmed, so the cutoff can never be silently bypassed. The fallback_refresh = false optimisation is set only after the remote-version list has already been fetched, so the fallback path always operates on fresh data without a second network round-trip. All three new scenarios are verified by unit tests with call-count assertions.

No files require special attention.

Important Files Changed

Filename	Overview
src/backend/mod.rs	Core logic change: always attempts latest_stable_version fast path, verifies cutoff against remote-version metadata, and reuses the cache on fallback. New helper function and three new unit tests cover all branches correctly.
e2e/backend/test_npm_install_before	Comment update only — accurately describes the new flow where the npm dist-tag candidate is attempted then rejected as newer-than-cutoff before falling back to the version list.

_{Reviews (3): Last reviewed commit: "fix(backend): verify latest stable cutof..." | Re-trigger Greptile}

[gemini-code-assist]

Code Review

This PR refactors the 'latest' version resolution to allow backends to use fast-path results even when date cutoffs are active, provided the candidate meets the date criteria. The Aqua backend was updated to support this by fetching the latest GitHub release, and helper functions were added for tag parsing and asset validation. E2E tests were also adjusted to verify cache reuse and fallback logic. A review comment identifies a potential performance bottleneck in the Aqua backend where package objects are cloned repeatedly within a loop.

[risu729]

CI note after the latest push: all non-Windows-e2e checks have completed successfully or skipped as expected. The only failures are:

• windows-e2e: failed in e2e-win\zig.Tests.ps1 because downloading https://pkg.hexops.org/zig/zig-windows-x86_64-0.14.0-dev.2577+271452d22.zip timed out on all three HTTP attempts.
• test-ci: failed only because it aggregates windows-e2e and reported windows-e2e failed or was skipped.

This stacked PR does not touch the Windows Zig test or that download host.

This comment was generated by an AI coding assistant.