chore: enable unified hybrid tests

[NoelStephensUnity]

Purpose of this PR

Stands up a dedicated CI job that runs the unified (NGO + N4E) hybrid-prefab integration tests, and
fixes the three bugs that were preventing UnifiedNetworkTransformTest from passing.

This is the first part of 3 PRs:

1. (This PR) gets the initial scaffolding into place.
2. chore: unified hybrid tests enabled environment var #4137 removes the test filter and uses the UNIFIED_TEST environment variable (almost exactly like CMB service tests with the difference that it is going to start out as a "turned off by default" for all tests and will be an "opt-in". The UniversalNetworkTransformTest is the only opt-in for 4137 ). 4137 also removes a bunch of the YAML comment verbosity along with other script file comments.
3. Yet to be posted PR that will include more NetworkTransformTests.

Additional unified netcode hybrid testing details

The pin for unified testing is 6000.7.0a5, not 6000.7.0a2 due to conflicts between the two.

The original plan was to pin a2 (breakpoints are more reliable there). a2 turns out to be unusable —
it cannot compile the unified code at all. Both alphas bundle com.unity.netcode 6.7.0, so the
package version does not distinguish them; only the trunk snapshot does. Verified by reading the
sources bundled in each editor:

symbol	a2	a5
IOutOfBandRpcCommand	0	2
OutgoingOutOfBandRpcDataStreamBuffer	0	20

UnifiedNetcodeTransport is gated on #if UNIFIED_NETCODE && OUT_OF_BAND_RPC and needs both.
Separately, a2 still names the component GhostAdapter; a5 renamed it to GhostObject, which is what
the test helpers call. Two independent blockers, so a2 is off the table regardless of debugger quality.

Runtime fixes

• UnifiedNetcodeUpdateSystem.OnCreate used the ISystem signature OnCreate(ref SystemState) on a
  SystemBase. Without override that is a new method Entities never calls, so neither
  RequireForUpdate took effect and OnUpdate ran from the first world tick — before
  StartClient/StartServer assign Transport and NetworkManager. CreateSingleWorldHost calls
  AppendWorldToCurrentPlayerLoop, so the world is live immediately and any tick in that window was a
  NullReferenceException. Corrected to the parameterless override, plus a null guard in OnUpdate.
• NetcodeIntegrationTest.SpawnObject set Netcode.Instance.m_ActiveWorld after
  Object.Instantiate. The hybrid prefab is active, so the clone's GhostObject.Awake runs
  synchronously inside Instantiate; the clone is not a prefab, so Awake acquires an entity reference
  and resolves the target world from that singleton. N4E's rate managers reassign it on every world
  update, so it pointed at whichever client world updated last and the spawn was rejected with
  "You can only spawn a ghost on a server or during prediction on a client." Assignment hoisted above
  Instantiate.
• NetworkObject.InitGhost threw when a hybrid prefab was created before any NetworkManager exists,
  which is the normal ordering in integration tests. Now returns early on a null NetworkManager.

CreateHybridPrefab also now calls GhostObject.InitializeAsPrefab() instead of hand-rolling the
GhostPrefabReference setup, which picks up N4E's try/finally reset of s_IsPostProcessing.
UnifiedNetworkTransformTest was hardened: position is validated on initial spawn as well as after
the move, and the fixed WaitForSeconds(1) is replaced with WaitForConditionOrTimeOut reporting
which client diverged and by how much.

Tradeoffs worth reviewer attention

• Duplicate manifest. manifest-unified.json is a full copy of manifest.json. It differs by more
  than the N4E entry: manifest.json pins the builtin versions that exist on 6000.6
  (addressables 2.11.1, timeline 6.6.0, ugui 2.6.0), which do not resolve on 6000.7.0a5. That
  means hand-syncing two manifests until N4E becomes a hard NGO dependency, at which point this goes
  away. I could not find a way to avoid the duplication without dropping 6000.6 support.
• Test selection is a name pattern. unified_test_filter: "*Unified*" matches the NUnit full test
  name, which covers the dedicated fixtures and is intended to also cover shared fixtures
  parameterized with HostOrServer.UnifiedHost/UnifiedServer. An NUnit [Category] would be less
  fragile once more fixtures gain unified variants; there is no [Category] usage in the package today
  and UnifiedTestRunner's --category support is unconfirmed, so this is deliberately deferred.
• This is in the PR gate. run_all_unified_tests is a dependency of pr_code_changes_checks,
  wired the same way as the CMB service tests. That puts an unsupported alpha editor into the mandatory
  gate: when N4E lands breaking changes in trunk this goes red and the pin has to be bumped before any
  PR can go green. Chosen deliberately over an opt-in trigger so unified breakage is noticed
  immediately. unified_pr_checks (/ci unified) remains for PRs the main gate does not cover.
• Bumping the pin means changing three things together: unified_editors.default,
  unified_netcode_version, and the com.unity.netcode version in manifest-unified.json.

Known gap: the CI job runs editor playmode; verification so far is a standalone player run.
See Testing & QA below.

Jira ticket

MTT-XXXX

Documentation

• No documentation changes or additions were necessary.

All changes are either CI configuration, test helpers, or runtime code behind #if UNIFIED_NETCODE,
which cannot be defined without com.unity.netcode installed. There is no public API surface change
and no behaviour change for any current NGO user.

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

Functional Testing

Manual testing :

• Manual testing done

A standalone player build containing only UnifiedNetworkTransformTest runs green locally
(Windows, Mono, 6000.7.0a5). Before the three fixes above this failed with
SetUp : Failed to start instances plus a NullReferenceException immediately after
"Starting a world for Host".

Also unverified: that com.unity.netcode: 6.7.0 resolves to the builtin copy from
manifest-unified.json on a clean checkout (locally it was added by hand to manifest.json), and that
Yamato accepts the new YAML.

Automated tests:

• Covered by existing automated tests

UnifiedNetworkTransformTest already existed; this PR fixes what it was failing on and strengthens its
assertions. The new coverage is at the CI level — the test now actually runs in CI, which it never did
before, since UNIFIED_NETCODE was never defined in any existing job.

Does the change require QA team to:

• Review automated tests?
• Execute manual tests?
• Provide feedback about the PR?

No QA involvement requested: this is CI infrastructure plus an experimental code path that is compiled
out of every shipping configuration.

Up-port

Not needed. This PR targets develop-3.x.x directly. The unified API does not exist in NGO v2.x, and
all runtime changes are behind UNIFIED_NETCODE, which cannot be defined there.

Backports

Not needed, for the same reason — this is specific to the NGOv3.X unified work.

[NoelStephensUnity]

This "pins" the NGO version of the unified NetcodeConfig to avoid having one auto-created.

[codecov-github-com]

Codecov Report

All modified and coverable lines are covered by tests ✅

@@              Coverage Diff               @@
##           develop-3.x.x    #4122   +/-   ##
==============================================
  Coverage          78.01%   78.01%           
==============================================
  Files                153      153           
  Lines              26254    26254           
==============================================
  Hits               20483    20483           
  Misses              5771     5771           

Flag	Coverage Δ
NGOv2_project_testproject_ubuntu_pinnedTrunk	77.70% <ø> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
....netcode.gameobjects/Runtime/Core/NetworkObject.cs	75.29% <ø> (ø)

Components	Coverage Δ
com.unity.netcode.gameobjects	78.01% <ø> (ø)

ℹ️ Need help interpreting these results?

[michalChrobot]

I'm not sure if we really need this part if those tests will run on each PR anyway (part of pr_code_changes_checks)

[NoelStephensUnity]

The triggers are removed in #4137

[michalChrobot]

So those tests are not included by default in any other job? Like usual package tests?

[NoelStephensUnity]

This is a larger set of changes broken into a 3 part PR.
This PR runs on other PRs and on the nightly.
#4122 is the initial framework to show it working.
#4137 makes the unified integration tests work almost exactly like the CMB service test. (this still runs on PRs and Nightly)

[michalChrobot]

Why we can't update our current manifest already? Would it require to move completely to testing on 6000.7?

[NoelStephensUnity]

Yeah... it would require us to remove all of the earlier editor versions.
We can do that, but we might wait until after all of the initial unified testing is done before switching over completely.

But based on yesterday's conversation we might hold off in case we decide to support 6000.3.

[michalChrobot]

I think we already got rid of all package-lock.json so maybe we can remove this line?

[NoelStephensUnity]

Good catch.

[michalChrobot]

Do we only support PlayMode tests? (otherwise it would be --suite=editor --suite=playmode)