docs(physics): correct stale set_velocity claim in the 4a remote velocity comment

LiveEntityNetworkUpdateController.cs's TryCommitAuthoritativeVelocity
call site carried a comment claiming "MoveOrTeleport installs that
exact vector with set_velocity". The C4 route 5 byte-decode of
CPhysicsObj::MoveOrTeleport @0x00516330-0x00516438 (the immediately
preceding commit) shows this is false: the function never reads its
velocity argument's stack slot in any branch, and UnpackPositionEvent
performs no set_velocity either. The only set_velocity in the whole
accepted-Position chain zeroes the LOCAL player @0x004541B4, a
different call site entirely.

This commit only corrects the comment. The 4a call itself is left
unchanged in production, deliberately out of C4 route 5's scope — the
route governs RuntimeSetPositionOperationKind placement dispatch, not
the pre-existing remote velocity commit. #317 (docs/ISSUES.md, filed
in the previous commit) tracks the follow-up: audit the whole
accepted-Position velocity chain and either find the correct retail
source or remove the call with a divergence-register row.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

src/AcDream.App/Physics/LiveEntityNetworkUpdateController.cs

@@ -2417,11 +2417,21 @@ internal sealed class LiveEntityNetworkUpdateController
                     update.Position.LandblockId);
             }
 
-            // PositionPack::UnPack initializes an absent velocity to zero;
+            // 4a-family correction (2026-08-04, found and reported while
-            // MoveOrTeleport installs that exact vector with set_velocity.
+            // pinning C4 route 5's D-P5 no-velocity design): the previous
-            // The canonical seam wakes the retained ObjectClock and body in
+            // comment here claimed "MoveOrTeleport installs that exact vector
-            // one operation. Position-delta velocity below remains animation
+            // with set_velocity". A byte-level disassembly of the PDB-paired
-            // diagnostics and is never substituted into physics.
+            // binary (0x00516330-0x00516438, every branch) shows
+            // MoveOrTeleport never reads its velocity argument's stack slot,
+            // and UnpackPositionEvent performs no set_velocity either — the
+            // only set_velocity in the whole accepted-Position chain zeroes
+            // the LOCAL player (@0x004541B4). This call's actual retail
+            // justification is therefore NOT yet established and needs its
+            // own audit; what IS still true and unaffected by that finding:
+            // the canonical seam below wakes the retained ObjectClock and
+            // body in one operation, and the Position-delta velocity further
+            // down remains animation diagnostics, never substituted into
+            // physics.
             if (!_liveEntities.IsCurrentPositionAuthority(
                     positionRecord,
                     acceptedPositionAuthorityVersion))