Fix upgrade modal recommending current version

What

The self-managed "Important notice - Critical patch release" upgrade modal could tell an admin to upgrade to the version they are already running. For example: "You are currently on version 19.4.1! ... upgrade to one of the following versions immediately: 19.4.1."

Why

Two separate problems combine:

1. Stale cache across upgrades. The daily VersionCheckCronWorker caches the version.gitlab.com response under a fixed key version_check that does not include the version. Rails.cache applies its default 8-hour TTL to the entry. The modal reads the running version live but reads the recommendation from that cache. After an upgrade the old pre-upgrade response keeps being served for up to about 8 hours, until the entry expires and the helper triggers a re-fetch (or the daily cron overwrites it, whichever comes first), so it recommends the version just installed.
2. No guard in the modal. The modal never removes the current version from the recommended list, so any stale or wrong response renders an "upgrade to the version you already run" message.

version.gitlab.com itself is correct; it returns a healthy response for a current patch version. The problem is entirely in GitLab.

Changes

• Include the running version in the cache key (version_check:<version>) in the worker (write) and helper (read), so an upgrade misses the old entry and the worker re-fetches.
• Filter the current version out of the recommended stable versions and the "additional patch for your minor" line in the modal.
• Update the worker, helper, and frontend modal specs.

Operational note

After this deploys, each instance re-fetches once because its old fixed-key cache entry is no longer read, then returns to the normal daily cron cadence.