[IMPROVEMENT] Align GitHub latest release metadata with the active stable release line

[B67687]

Describe the improvement

GitHub's releases/latest endpoint for this repository currently resolves to 3.3.7, and that release is still marked as Latest.

At the same time, the repository also has newer non-prerelease releases in the v2026.* line, with v2026.1.4 currently being the newest one.

If the v2026.* line is the intended current stable release line, could the GitHub release metadata be adjusted so the Latest marker and /releases/latest redirect point to that line instead of 3.3.7?

I checked for existing reports first and did not find one that matched this release-metadata case.

Concrete repo behavior I observed:

• gh api repos/Devolutions/UniGetUI/releases/latest returns tag_name: 3.3.7
• gh release list -R Devolutions/UniGetUI --limit 15 shows newer non-prerelease releases up to v2026.1.4

If this is intentional and 3.3.x is still meant to be the canonical stable line, feel free to ignore this.

Describe how this improvement could help users

This would make the repository's public release metadata less ambiguous for users and for downstream tools that intentionally follow GitHub's stable Latest release signal while ignoring prereleases.

One example is package managers and update checkers that use /releases/latest specifically so they do not have to invent custom repo-specific rules. Right now those tools still see 3.3.7 as the latest stable release even though newer v2026.* releases exist.

[mamoreau-devolutions]

If this is intentional and 3.3.x is still meant to be the canonical stable line, feel free to ignore this.

Unfortunately, 3.3.7 is still marked as the latest release in GitHub Releases intentionally, even if it's a bit confusing. The reason is that previous builds of UniGetUI check for an update file with an explicit version, but when downloading the assumed-to-be-latest version, it always uses the one marked as latest in GitHub Releases. This caused #4482, so we are leaving 3.3.7 marked as latest.

This is a temporary measure, we have yet to trigger the auto-update on everyone using 3.3.x through the in-app updater. When we do this, we'll be able to synchronize both the update file and GitHub Releases with the assistance from Marti Climent. All those that installed or updated to 2026.1.x builds use a new update check system from Devolutions that doesn't have this issue.