Evaluate compatibility per RFC 0017 and the os list per RFC 0031

[Maximilian-Nesslauer]

ModVersionMetadata carries GameMinRevision, GameMaxRevision and Os.

RFC 0017 defines four states:

State	Condition
Unknown	No usable lower bound.
Incompatible	The installed revision is below the lower bound.
Compatible	The upper bound is absent, or the installed revision is at or below it.
Untested	The installed revision is above a stated upper bound.

Incompatible is the only state that blocks.
This classifies only; what a client does with Untested and Unknown is a UI decision and not part of this issue.

Shape, in Borea.Core:

• enum GameCompatibility { Compatible, Untested, Incompatible, Unknown }
• Evaluate(int? minRevision, int? maxRevision, GameVersion installed), plus an overload taking a ModVersionMetadata.
• Compare installed.Revision against the bound integers directly.

On Unknown: ModVersionMetadata requires gameMin and a non-nullable GameMinRevision, so the release overload can never return Unknown and there is no "no bounds at all" case for a release. That is expected, not a gap to fix here. Unknown exists for the listing side, where SpaceDockModRepository maps an unparseable game version to GameMin = "unknown". The nullable parameter is what makes the state reachable.

The os list, from the same [compatibility] table. RFC 0031: "A platform outside the stated os list warns and lets the user proceed: the list states what the author knows works, not everything that can." Advisory, never blocking.

• The vocabulary is windows, linux, macos; the RFC adds "New values arrive by RFC".
• The check takes the target platform as a parameter and never reads the running OS, so it stays testable on the three-OS CI matrix.
• Absent means no known restriction. Treat an empty list the same way, and say in a comment that this is our choice: the RFC defines only absent, and the domain deliberately keeps empty distinct from absent.
• Compare case-insensitively as client leniency; the RFC states no comparison rule for os.
• An unrecognised value must not make the list unusable and must not be silently dropped: keep evaluating the recognised entries and report the unrecognised ones, so a caller can say the listing knows a platform this build does not.
• Give the Unknown member a doc comment saying it means no usable compatibility data, because ModStatus.Unknown and ReleaseStatus.Unknown already use the name for "a value this client version does not know".