docs: Condense interpolation render time comments and changelog

Comment and changelog wording only, no behavioral or test logic changes.

Trims the explanation in UpdateInterpolation from twenty one lines to six and
drops the measurement anecdote and the unfilled Jira placeholder, keeping the
reason the server clock is the correct one to measure from. Shortens the test's
remarks and constant comments to match the density of the surrounding tests.

The removed detail, the measurements behind the fix, and the metrics that were
tried and rejected while building the test are recorded outside the repository.

Author: NoelStephensUnity

com.unity.netcode.gameobjects/Runtime/Components/NetworkTransform.cs

@@ -4259,26 +4259,12 @@ internal BufferedLinearInterpolatorQuaternion GetRotationInterpolator()
         // Non-Authority
         private void UpdateInterpolation()
         {
-            // Use the server time, because that is the clock the measurements being interpolated between are
-            // stamped on: a state's SentTime is derived from its NetworkTick, which is a server tick.
-            //
-            // Deriving the render time from LocalTime instead mixes two clocks. LocalTime leads ServerTime by
-            // roughly the tick latency, so subtracting the tick latency from it lands the render time back at
-            // (approximately) ServerTime rather than behind it. "Approximately" is the problem: the lead is
-            // fractional while the subtraction is a whole number of ticks, and a state's SentTime is floored to
-            // a tick boundary on top of that. The render time therefore ends up at or slightly ahead of the
-            // newest state that can exist, leaving the interpolator with nothing to interpolate towards. A
-            // measured session had the render time ahead of ServerTime on 100% of frames, with the interpolator
-            // never holding more than one measurement.
-            //
-            // Measuring from ServerTime instead makes the offset the whole tick latency rather than whatever is
-            // left of it, which is self correcting: as the round trip time grows, NetworkTimeSystem.TickLatency
-            // grows and the render time moves further back with it.
-            //
-            // Note this is a no-op on a host or server, where LocalTime and ServerTime are the same.
-            // TODO-JIRA-TICKET:
-            // Confirm the distributed authority case. Authority instances interpolate nothing, so this should
-            // not reach them, but ServerTime's meaning under a CMB service session should be verified.
+            // Use the server time, since that is the clock the states being interpolated between are stamped on
+            // (a state's SentTime is derived from its NetworkTick). Deriving the render time from LocalTime
+            // subtracts the tick latency from a clock that already leads ServerTime by roughly that much, which
+            // leaves the render time at or ahead of the newest state that can exist and starves the interpolator.
+            // Measuring from ServerTime is also self correcting, as the tick latency grows with the round trip
+            // time. This is a no-op on a host or server, where both clocks are the same.
             var timeSystem = m_CachedNetworkManager.ServerTime;
             var currentTime = timeSystem.Time;
 #if COM_UNITY_MODULES_PHYSICS || COM_UNITY_MODULES_PHYSICS2D

com.unity.netcode.gameobjects/Tests/Runtime/NetworkTransform/NetworkTransformInterpolationRenderTimeTests.cs

@@ -13,32 +13,20 @@ namespace Unity.Netcode.RuntimeTests
     /// clock that the state updates it is interpolating between are stamped on.
     /// </summary>
     /// <remarks>
-    /// A <see cref="NetworkTransform"/> state's SentTime is derived from its NetworkTick, which is a server
-    /// tick, so the render time has to be measured from ServerTime. Measuring it from LocalTime mixes two
-    /// clocks: LocalTime leads ServerTime, so subtracting the tick latency from LocalTime lands the render time
-    /// back at approximately ServerTime rather than a whole tick latency behind it. The interpolator is then
-    /// asked to render a point in time at (or ahead of) the newest state that can possibly exist, so it has
-    /// nothing left to interpolate towards.
-    ///
-    /// What this test measures is how far behind ServerTime the state currently being interpolated towards was
-    /// sent. Because the target is selected against the render time, this has to be at least the tick latency:
-    /// the render time is ServerTime minus the tick latency, and only states sent at or before the render time
-    /// are eligible. Deriving the render time from LocalTime instead eats into that margin by however far the
-    /// two clocks are apart, and can push the target past ServerTime entirely (a negative value below, meaning
-    /// the interpolator is chasing a state that the server clock says has not happened yet).
+    /// Measures how far behind ServerTime the state being interpolated towards was sent. The render time is
+    /// ServerTime minus the tick latency and only states sent at or before it are eligible, so that measurement
+    /// can never be less than the tick latency. Deriving the render time from LocalTime eats into that margin by
+    /// however far the two clocks are apart, and can push the target past ServerTime entirely.
     /// </remarks>
     [TestFixture(HostOrServer.Host, NetworkTransform.InterpolationTypes.Lerp)]
     [TestFixture(HostOrServer.Host, NetworkTransform.InterpolationTypes.SmoothDampening)]
     internal class NetworkTransformInterpolationRenderTimeTests : IntegrationTestWithApproximation
     {
         protected override int NumberOfClients => 1;
 
-        // How far LocalTime is pushed ahead of ServerTime, in ticks. An in-process integration test has
-        // effectively no round trip time and the separation between the two clocks is
-        // (half RTT + LocalBufferSec + ServerBufferSec), so without widening the local buffer the two clocks
-        // sit close enough together that which one is used barely shows. This is deliberately large enough to
-        // exceed NetworkTimeSystem's hard reset threshold (0.2s) so the offset snaps rather than converging at
-        // the default adjustment ratio of 0.01s per second, which would take over ten seconds.
+        // How far LocalTime is pushed ahead of ServerTime, in ticks. An in-process test has no round trip time
+        // to separate the two clocks, and this is large enough to exceed NetworkTimeSystem's hard reset
+        // threshold so the offset snaps instead of converging at its default adjustment ratio.
         private const int k_LocalBufferTicks = 12;
 
         // The separation the clocks must actually reach before any measurement is taken.
@@ -47,11 +35,10 @@ internal class NetworkTransformInterpolationRenderTimeTests : IntegrationTestWit
         // Ticks of authority motion after the clocks have separated, so the interpolator reaches steady state.
         private const int k_WarmUpTicks = 20;
 
-        // The number of rendered frames sampled once the warm up has completed.
         private const int k_SampledFrames = 90;
 
-        // The distance the authority moves each tick. Large enough that every tick produces a state update
-        // rather than being filtered out by the position threshold.
+        // Far enough each tick that every tick produces a state update rather than being filtered out by the
+        // position threshold.
         private const float k_DistancePerTick = 1.37f;
 
         private readonly NetworkTransform.InterpolationTypes m_InterpolationType;
@@ -223,9 +210,7 @@ public IEnumerator RenderTimeTrailsTheServerClock()
                 var meanBuffered = totalBuffered[instance] / (float)samples[instance];
                 var tickLatency = networkManager.NetworkTimeSystem.TickLatency;
 
-                // Only states sent at or before the render time are eligible to be interpolated towards, and the
-                // render time is the server clock minus the tick latency, so the target can never be newer than
-                // that. Anything less means the render time was taken from a clock that runs ahead of the one
+                // Anything less than the tick latency means the render time came from a clock that leads the one
                 // the states are stamped on.
                 Assert.GreaterOrEqual(meanTargetLagTicks, tickLatency,
                     $"[{m_InterpolationType}] {instance.name} was interpolating towards a state sent " +