RFC：Add minimum-release-age for Vite+ version selection

Context

Setting version to latest lets you pick up new Vite+ releases without manually bumping versions. It's also what setup-vp falls back to when it can't resolve a version from the project.

Current version resolution process

The downside is that CI can pick up releases immediately after publication. To mitigate supply chain risks, it'd be useful to have a waiting period before adopting brand-new versions. Pinning versions works, of course, but a delay lets people keep auto-updating while allowing time for problems or compromised releases to be discovered. This doesn't guarantee security. mise-action already supports something similar with its minimum_release_age option.

This applies only to the Vite+ CLI itself, not project dependencies.

Proposal

Add an optional minimum-release-age input.

- uses: voidzero-dev/setup-vp@v1
  with:
    version: latest
    minimum-release-age: 3

The input would take a non-negative integer representing days (24-hour periods). Setting it to 3 means a release must be at least 72 hours old.

Expected behavior:

• When resolving latest (or falling back to it), pick the highest stable version that meets the age requirement.
• Leave pinned versions and versions resolved from lockfiles unchanged.
• Omitting the input or setting it to 0 keeps the current behavior.
• Reject invalid values, such as negative numbers or non-integers, with a clear error.
• When an age requirement is enabled, fail with a clear error if no release qualifies or publication metadata cannot be retrieved, rather than silently bypassing the requirement.
• Log the chosen version along with its publication timestamp.

One tradeoff is that CI may select an older version than a local environment using the current latest. Explicitly setting version: latest also takes precedence over project version detection. Users who need matching versions should pin Vite+ in their project and let setup-vp resolve that version.

I think scoping this to latest makes sense for now. Ranges and prerelease tags can be considered separately. Ideally, the selection logic would be shared across the GitHub, GitLab, and Azure entry points.

This might be more defensive than necessary for setup-vp, so I'd appreciate your candid thoughts on whether it belongs here.