Detect in-place release asset re-uploads in update check

[DysektAI]

Summary

A hotfix re-published under an existing release tag currently leaves users silently running a replaced build: the update check only compares version numbers, and an in-place asset re-upload does not change the tag. This PR makes the update check also detect when the TarkovMonitor.zip asset of the current release has been re-uploaded, so affected users get the existing "new version available" notification instead of nothing.

Changes

• UpdateCheck.cs — the check now reads the release's assets payload and compares the TarkovMonitor.zip asset's updated_at against the last observed value. The baseline is seeded silently on first sighting, so fresh installs work. Notifies when:
  • the version is newer (unchanged behavior), or
  • the running build is the same version but its release asset was replaced in place
• Properties/Settings.settings + Properties/Settings.Designer.cs — two new user-scoped string settings: lastSeenReleaseTag and lastSeenReleaseAssetUpdatedAt
• App.config — mirrors the new settings under <userSettings> so the settings designer does not produce an unrelated regeneration diff

Behavior notes

• Fresh installs work: the baseline is seeded on the first check without notifying; a later re-upload is then detected.
• Notification fires once for a same-version re-upload: since the version does not change, there is no way to tell whether the user acted on it, so re-nagging would be inescapable. Documented in the code.
• Degrades gracefully: a missing/empty assets payload never reads as a change and never poisons the stored baseline — the check falls back to the original version-only behavior.
• Settings.Save() is only called when the observed state actually changed (no daily redundant disk writes for users on an old version).

Scope

4 files, +65/−2. No version bump, no new dependencies, no changes outside the update check.

Verification

• dotnet build -t:Rebuild: 0 errors; the 4 pre-existing CS8618 warnings in UpdateCheck.cs are untouched and the new code adds none
• Decision logic exercised through a 14-case harness (fresh install, re-upload detection and once-only semantics, daily nag while outdated, no spurious toast after updating, missing-assets glitches, dev build newer than release, new tag mid-flight, save gating): all pass; harness not committed
• Confirmed the release workflow's -p:Version=<tag> override makes localVersion == remoteVersion hold exactly for real releases

[Razzmatazzz]

Actually, rather than adding additional settings and complexity, I should probably just try harder to not fumble releases.

[GiribaldiTTV]

Actually, rather than adding additional settings and complexity, I should probably just try harder to not fumble releases.

we are human, i think this is a good change to add, but i only glanced at it.