Minimal supported editor correction

[michalChrobot]

Purpose of this PR

While looking at https://discussions.unity.com/t/problem-with-netcode-1-0-2/1701859/2 I was wondering why package manager was not suggesting updates to latest NGO version and while this is probably related to the fact that user was working un unsupported tech stream of Unity editor and this is not NGO fault I realized one issue that we have

In our package.json we use "unity": "6000.0" and in contrast to Netcode for Entities implementation we are not using "unityRelease": "0f1". The difference is as follows:

1. Behavior with unityRelease specified
With the configuration "unity": "6000.0" and "unityRelease": "0f1", the Package Manager interprets this as a strict minimum requirement.

Minimum Version: The package explicitly declares that it requires Unity 6000.0.0f1 or higher.
Behavior: If a user tries to install this package on an Editor version lower than this (e.g., 6000.0.0b10), the Package Manager will flag it. Specifically, if installed on an older version, the Package Manager window will display an info icon in the details header indicating that the package version is not recommended for that Unity version.

2. Behavior without unityRelease specified
If we don't have "unityRelease": "0f1" and leave only "unity": "6000.0", the restriction becomes broader.

Minimum Version: The Package Manager considers the package compatible with the entire 6000.0 cycle (and newer).
Behavior: It effectively sets the "floor" to the beginning of that major/minor version cycle. It will not complain if the user is on a beta or alpha of 6000.0, provided the major.minor matches or exceeds the requirement.

Our issue is that in our CI we specified minimum editor to 6000.0 and while using unity-downloader-cli -u {{editor}} command the tool fetches the latest available release for that version stream (e.g., 6000.0.36f1), not the initial release (e.g., 6000.0.0f1).
It is not fair or safe to claim support for 6000.0 (which implies 6000.0.0f1 and up, also alpha and beta versions) while only testing on the latest patch (e.g., 6000.0.36f1).

The risk is that we develop and test only on 6000.0.36f1 and we might inadvertently use an API or a bug fix that was introduced in 6000.0.20f1.
As a consequence the user running 6000.0.5f1 will be able to install our package (because our package.json says 6000.0 is fine), but the package will crash or fail because the API it relies on doesn't exist in their editor version.

To resolve this I specified "unityRelease": "0f1" and set minimal test editor to that version (6000.0.0f1). This means that

1. We specifcally offer support to all supported 6000.0 editors while having a safe minimal requirement
2. We perform our validation on PRs with latest (trunk) and proper minimal editor (6000.0.0f1) wile running all other tests daily/weekly (6000.0.0f1, 6000.0, 6000.3 etc)
3. If something will start failing in relation to editor API then we can "simply" increase this minimal patch version as needed
4. We will avoid unexpected failures on our PRs due to API changes in latest 6000.0 editor while we will still be able to catch those via daily/weekly tests. So our tests on PRs should be a bit more stable

Jira ticket

I will add

Changelog

• Changed: Minimal supported editor was set to LTS version 0f1 which means that we do not guarantee that the package will work on alpha or beta versions of 6000.0

Documentation

N/A

Testing & QA (How your changes can be verified during release Playtest)

I will run our CI triggers to see if everything is executed as expected

Backports

Will do