A NetworkTransform state's SentTime comes from its NetworkTick, which is a
server tick, but the render time the interpolators were given was derived from
LocalTime. That mixes two clocks. LocalTime leads ServerTime, so subtracting
the tick latency from it lands the render time back at approximately ServerTime
rather than a whole tick latency behind it, and a state's SentTime is floored to
a tick boundary on top of that. The render time therefore sat at or ahead of the
newest state that could exist and the interpolator had nothing to interpolate
towards.

Measuring from ServerTime makes the offset the whole tick latency instead of
whatever is left of it, and is self correcting: as the round trip time grows the
tick latency grows and the render time moves further back with it. This also
matches the rest of the component, which already resets the interpolators using
ServerTime.

This is a no-op on a host or server, where the two clocks are the same, so it
only affects clients.

GetTickLatencyInSeconds returns an absolute time rather than a duration and had
the same defect, so it now derives from ServerTime as well. GetTickLatency is
left alone because it returns a tick count rather than a point in time.

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.

GetTickLatencyInSeconds returned TimeTicksAgo(...).Time, which is an absolute
network timestamp rather than a duration, so the value grew for as long as the
session ran. It is documented as returning the tick latency in seconds, and
NetworkTimeSystem.TickLatency points at it as a way to inspect that latency, so
the contract was misleading regardless of which clock it was measured from. It
now returns the tick count multiplied by the tick interval.

This also takes the clock question out of this method entirely, since a duration
does not reference LocalTime or ServerTime. The change to derive interpolation
render time from ServerTime now applies only to UpdateInterpolation.

Adds integration tests covering the documented contract: the value tracks the
tick latency rather than elapsed time, and lengthens by exactly the tick
interval for each tick of additional buffering. Both fail against the previous
implementation, the second regardless of how long the session has run, since
buffering more ticks used to make the reported latency smaller.

Removing using directive for UnityEngine as it is an unused namespace.

NetworkTimeSystem.TickLatency is recomputed from the averaged round trip time
and can legitimately change mid-run. Both tests assumed it would not, and one
failed on macOS when it moved from two ticks to three, reporting the value as
having gone from 0.0666s to 0.1s.

The duration is now only held to being unchanged across samples where the tick
latency itself did not change, and the buffer offset test accounts for any tick
latency movement between its two samples so that only the buffering is held to
an exact figure.

Both still fail against the previous absolute timestamp implementation.