Improve package-filter latest fallback for multi-track releases

Improvement

The current @verdaccio/package-filter fallback for latest is based on publish time. This preserves existing behavior, but it can produce surprising results when a package has multiple active release tracks.

Current behavior

When a filtered version is removed from the manifest:

• dist-tags that point to removed versions are cleaned up.
• only the latest tag is backfilled.
• the fallback chooses the newest remaining stable version by time, or semver order if no time data exists.
• custom tags such as latest-4, beta, or next are not recomputed.

Problem

For packages with multiple release lines, publish time does not necessarily represent the correct release track.

Example based on Express-style releases:

{
  "4.22.0": "2025-12-01T16:23:07.582Z",
  "5.2.0": "2025-12-01T16:23:57.541Z",
  "5.2.1": "2025-12-01T20:49:43.268Z",
  "4.22.1": "2025-12-01T20:50:41.122Z",
  "4.22.2": "2026-05-11T18:50:00.007Z"
}

If latest points to 5.2.1 and that version is filtered, the current fallback may choose a remaining version from a different major line, for example 4.x, because it only considers publish time among untagged versions. That is not release-track aware.

For a custom tag like latest-4, if 4.22.2 is filtered, the tag currently disappears. That is probably safer than guessing what the custom tag means, but it is worth documenting as intentional behavior.

Suggested behavior

Keep the compatibility fallback for latest, but make it semver-aware:

• remember the original latest version before cleanup.
• if latest was filtered, choose a replacement only from the same semver major line as the original latest.
• prefer the newest valid stable version in that same line.
• if no version remains in that semver line, remove latest instead of falling back to another release track.
• do not automatically recompute custom dist-tags such as latest-4, next, or beta, because Verdaccio cannot know their intended semantics.

Notes

This should probably be handled in a separate PR from the current package-filter work. It is likely a rare edge case because it only happens when a filtered/deprecated version was the target of latest, but the behavior can be risky for packages with multiple release tracks.