feat(physics): C4 route 2 — ForcePosition through the canonical placement

A local-player ForcePosition had TWO independent writers for one accepted
packet: LocalForcePositionTransaction snapped the physics body
(PlayerMovementController.BlipPosition, a raw SnapToCell with no collision
resolve), while LiveEntityNetworkUpdateController's generic tail separately
wrote position/cell/rotation to the render WorldEntity from the raw wire and
rebucketed it. Two stores, one packet — the divergence class 670f307c fixed on
the remote path. The outbound AutonomousPosition ack also fired BEFORE any
canonical commit existed: we told ACE "got it, I'm here" before deciding where
"here" was, and the trailing isCurrent() could only suppress the continuation,
never recall the packet.

RuntimeAcceptedPositionDriveController is now the one Runtime-owned seam. Both
hosts call the identical TryExecuteAcceptedLocalPosition; App and headless
project the committed result through the existing placement projection sink
(LiveEntityRuntime.TryApplyRuntimePlacementPlace already performed the same
four writes, from committed state rather than a wire guess).

Retail: SmartBox::HandleReceivedPosition @0x00453FD0's FORCE_POSITION branch is
get_heading -> Frame::set_heading -> SmartBox::BlipPlayer @0x00453940 -> stamp
POSITION_TS -> SendPositionEvent @0x00454091 -> return @0x0045409D. BlipPlayer
is CPhysicsObj::SetPositionSimple @0x005162B0 with flags 0x1012
(Teleport|Slide|SendPositionEvent) — a real collision-resolving SetPosition,
not a snap. The pinned classifier already encoded this exactly.

Named behaviour changes:

* The ack is now an OUTPUT of the committed route, fired strictly after the
  canonical commit and exactly once per accepted force packet.
* The ForcePosition route no longer re-arms the constraint leash. The force
  branch returns at 0x0045409D, ahead of all three ConstrainTo sites
  (0x00454272, 0x0045418A, 0x004541EC); the old re-arm cited retail's "Player,
  normal" branch, which BlipPlayer is not on. The teleport, CommitPreparedPosition
  and first-entry callers legitimately still constrain and are untouched.
* A force correction that terminates WITHOUT committing still sends its
  position event and is not retried — retail's BlipPlayer discards
  SetPositionSimple's SetPositionError return and acks unconditionally.

A single _pending funnel owns the in-flight placement, deciding on the token's
PositionAuthorityVersion against the record's: equal -> clear; advanced with the
newest accepted event still a force -> re-issue, re-classified; advanced to an
ordinary Apply -> clear, since newer server truth owns that pose. This closes a
double-apply/double-ack and a silently-dropped correction that two earlier
iterations of this slice each introduced.

AD-62 records the residual: a ForcePosition our async collision publication
cannot carry to a committed placement is not re-applied. Retail has no park —
its world is fully resident and its placement synchronous — so the state is
unreachable there. AP-131 is NOT retired; its legacy Position caller is route 4.

Deleted: LocalForcePositionTransaction, PlayerMovementController.BlipPosition,
HeadlessSessionWorldProjection.BlipLocalPlayer.

Gates: complete Release solution 10,858 passed / 4 skipped / 0 failed (baseline
10,844/4/0). Two independent Opus reviews (retail-conformance and
architecture/adversarial) PASS on the final diff after three FAIL rounds; every
intermediate state was fully green, so the suite caught none of the four real
defects. Connected acceptance is NOT run: nothing a user can do makes ACE emit
a ForcePosition without retail's @pklite, which acdream does not implement — see
docs/research/2026-08-03-c4-route-2-visual-gate.md.

Known gap, recorded not claimed: the plan's acceptance item 2 is unmet. The App
double-write check is a source pin, and "the committed projection moves the
render entity" is uncovered at any layer (#292). Filed alongside: #286-#291,
#293-#296.

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

docs/ISSUES.md

@@ -140,6 +140,302 @@ reconciling #281's 43 test failures.
   fired — the log shows zero `world frame is unreachable` failures and zero
   parked placements across 9 completed reveals.
 
+## C4 route 2 — ForcePosition placement cutover — 2026-08-03
+
+Plan: [`2026-08-03-c4-route-2-implementation-plan.md`](research/2026-08-03-c4-route-2-implementation-plan.md);
+contract: [`2026-08-03-c4-route-2-contract.md`](research/2026-08-03-c4-route-2-contract.md).
+
+- **#285 — DONE (2026-08-03) — a ForcePosition on the local player wrote two
+  independent stores from one packet, and the outbound ack left before any
+  canonical commit existed.** `LocalForcePositionTransaction.Apply`
+  (App)/`HeadlessSessionWorldProjection.BlipLocalPlayer` (headless) drove
+  `PlayerMovementController.BlipPosition` — a raw `PhysicsBody.SnapToCell`
+  with no transition, no collision, no contact-plane resolve, no
+  `FullCellId`/`PlacementCommitVersion` advance — while the generic tail
+  (`LiveEntityNetworkUpdateController.cs`) independently wrote the
+  render-facing `WorldEntity` from the same wire frame; the App/no-window ack
+  (`LocalPlayerOutboundController.SendImmediatePosition`) fired immediately
+  after the blip, before either write's result was known. Same divergence
+  class as the remote-placement bug `670f307c` fixed.
+  **Fix:** `RuntimeAcceptedPositionDriveController`
+  (`src/AcDream.Runtime/Session/RuntimeAcceptedPositionDriveController.cs`) is
+  the single Runtime-owned accepted-Position execution seam for a
+  ForcePosition on an already-live local player: it drives the SAME
+  `RuntimeSetPositionState.TryBeginExclusiveAuthoredPlacement` +
+  `TryPrepareAndSubmitAuthoredPlacement` transaction every other placement
+  uses (retail `CPhysicsObj::SetPositionSimple` @0x005162B0, flags `0x1012`,
+  called from `SmartBox::BlipPlayer` @0x00453940), reconciles the
+  controller's render-lerp/cell state
+  (`PlayerMovementController.CommitCanonicalForcePositionFrame`, replacing
+  the deleted `BlipPosition`), and fires the ack strictly AFTER that commit —
+  never before it. `LocalForcePositionTransaction.cs` and
+  `HeadlessSessionWorldProjection.BlipLocalPlayer` are deleted outright, not
+  adapted; the generic render-tail write is skipped for the local player's
+  ForcePosition (App now projects the committed result through the existing
+  `RuntimePlacementPresentationSink`, the same seam every other placement
+  already uses).
+  **Two named behaviour changes, both retail-exact per this session's
+  verification:** (1) the outbound `AutonomousPosition` ack is now an OUTPUT
+  of the committed route, not a step alongside it — retail's
+  `cmdinterp->SendPositionEvent()` @0x00454091 runs after
+  `SmartBox::BlipPlayer` @0x00454074 returns, and the deleted transaction's
+  trailing `isCurrent()` recheck (which could only suppress the
+  *continuation*, not an ack that had already left) is now structurally
+  impossible; (2) the constraint leash is NOT re-armed on this route — every
+  `CPhysicsObj::ConstrainTo` call in `HandleReceivedPosition`
+  (@0x00454272/0x0045418A/0x004541EC) is on a branch the FORCE_POSITION early
+  return (@0x0045409D) never reaches. `BlipPosition`'s leash re-arm (added at
+  #167 Slice P5, commit `7719d25b`) was an unbacked deviation for this exact
+  branch — it was correct for retail's "Player, normal" branch that Slice P5
+  was modeling in general, but `SmartBox::BlipPlayer` is not on that branch.
+  #167's own historical write-up (below) is superseded for its `BlipPosition`
+  half by this entry.
+  **New behaviour (retail fidelity gain, not a regression):** the ForcePosition
+  now runs retail's REAL `SetPosition` collision resolve — a placement sphere
+  or authored Setup, not a bare teleport-shaped snap — so a corrected Z can
+  differ from the wire's literal Z by the placement sphere's own settle.
+  **R7 review correction (2026-08-03):** the FIRST implementation pass wrote
+  this paragraph against a fixture bug, not retail behavior — its headless
+  test fixture's dummy Setup sphere had its centre AT the origin (offset ==
+  radius), which lifted a settled origin a FULL 0.48 m radius above the
+  floor and was asserted as if that were the retail-correct answer. Retail's
+  `BlipPlayer` has never lifted the origin by a sphere radius. The real dat
+  human Setup `0x02000001`'s foot sphere is `(0,0,0.475) r=.48`
+  (`Ts46SphereListConformanceTests.cs:35-39`), whose bottom sits at
+  `origin + 0.475 − 0.48 = origin − 0.005` — so a settled origin lands
+  **within 5 mm** of the floor it rests on, not a sphere radius above it.
+  The headless fixture now uses the dat-exact sphere and asserts the
+  measured `Z = 50.005f` (`HeadlessSessionHostTests.cs`,
+  `WorldProjectionIgnoresNormalEchoButBlipsForcePosition`).
+  Runtime tests: `tests/AcDream.Runtime.Tests/Session/RuntimeAcceptedPositionDriveControllerTests.cs`
+  (classification/NotApplicable guards, ack-strictly-after-commit, ack
+  exactly once, the displaced-authority Contention case, the DeferredCell
+  park→wake→commit sequence, heading preservation, leash NOT re-armed, and —
+  added in the fix round — re-issue-from-canonical when a subsequent
+  accepted Position's merge-time `Forget` cancels a watched DeferredCell
+  park). **R8 review correction (2026-08-03):** the DeferredCell test's name
+  and assertions in the FIRST pass claimed a single-ack-after-wake sequence
+  the fixture does not exercise — this fixture's cross-landblock resolve
+  measures `InContact=false` (no subsequent physics tick sweeps the body
+  onto the terrain in this bare-Runtime harness), so no ack fires after the
+  wake at all today. The test is renamed
+  `DeferredCell_ParksThenCommitsAndNeverDoubleAcksAfterTheCollisionGenerationWakes`
+  and no longer pins the current zero-ack count with an assertion (a pinning
+  `Assert.Empty` would fail — and read as a regression — the day Contact
+  correctly starts flipping); it captures the ack count once and asserts
+  only that further `Advance()` pumps never change it. The
+  park→wake→commit→single-ack sequence remains unverified pending a harness
+  that drives a real physics tick to establish ground contact.
+  **Fix-round corrections (2026-08-03), both dual reviews having FAILed the
+  first pass — see
+  [`2026-08-03-c4-route-2-review-findings.md`](research/2026-08-03-c4-route-2-review-findings.md)
+  for the full R1-R9 list:** (R1, HIGH) the DeferredCell park could not
+  survive in production — `RuntimeEntityObjectLifetime.TryApplyPosition`
+  Forgets the entity's in-flight SetPosition on EVERY accepted Position (any
+  disposition), so a park outliving one ACE broadcast (~100-200 ms) was
+  cancelled before its collision generation could ever commit it, silently
+  losing the correction forever. `RuntimeAcceptedPositionDriveController.Advance`
+  now detects the dead watch (`IsPlacementCompletionTracked`) and re-issues
+  the SAME route from the entity's current canonical snapshot rather than
+  leaking `_pending`. (R2, HIGH) headless lost `BlipLocalPlayer`'s collision-
+  neighborhood re-centering; restored via the new
+  `IRuntimeDirectWorldProjection.CenterOnAcceptedForcePosition`. (R3, HIGH)
+  the headless login-window ForcePosition fallback was dropped; restored.
+  (R4, MEDIUM-HIGH) the force-ack was stealing a `Place` receipt the
+  presentation sink had legitimately declined for its own retry contract;
+  removed. (R5, MEDIUM-HIGH) corrected the `Rejected` status doc's false
+  "no SetPosition ran" claim. (R6, MEDIUM) `_pending` could leak forever on
+  a mid-session cancellation (now caught by the same R1 detection) and
+  `SubmitAndResolve` could silently overwrite a still-live pending (now
+  guarded, throws on the invariant violation). (R9, LOW hygiene) a stale
+  `BlipPosition` doc cref, `HeadlessSessionHost._currentSession` never
+  cleared on teardown, and the streaming observer/pose-dirty side effects
+  firing for a `Rejected`/`Contention` status the route explicitly declined
+  to place into. Complete Release solution after the fix round:
+  **10,853 passed / 4 skipped / 0 failed** (10,857 total) — App 4,058/3,
+  Bake 15/0, Cli 4/0, Content 124/0, Core.Net 762/0, Core 4,247/1, Headless
+  79/0, Runtime 1,021/0, UI.Abstractions 543/0.
+  **Round 2 fix (2026-08-03), both delta reviews having FAILed the fix round
+  — see the "ROUND 2" section of
+  [`2026-08-03-c4-route-2-review-findings.md`](research/2026-08-03-c4-route-2-review-findings.md):**
+  round 1 bolted the re-issue onto ad-hoc per-branch `_pending` bookkeeping,
+  which had no single owner and no single lifecycle rule; that is the shared
+  root cause of all three round-2 blockers. Replaced with ONE funnel:
+  `RuntimeAcceptedPositionDriveController.SettlePending` is the sole terminal
+  writer of `_pending`, `RetainPending` the sole outstanding writer, and
+  `AbandonPending` the sole teardown writer. Its ONE decision input is the
+  terminal operation token's `PositionAuthorityVersion`
+  (`RuntimeSetPositionState.cs:50`) versus the live record's current value —
+  equal ⇒ clear, no re-issue (fixes **N1**: one server correction now
+  produces exactly one canonical placement and exactly one outbound
+  `AutonomousPosition`, never two); advanced with the newest accepted event
+  still a ForcePosition ⇒ re-issue it, re-classified from the current record
+  via the newly recorded `_newestForce` observation (fixes **B1**: a
+  correction blocked by a woken park's retained completion is no longer lost);
+  advanced with the newest accepted event now an ordinary `Apply` ⇒ clear, no
+  re-issue (fixes **N2**: the round-1 shape reused the stale force route and
+  would have applied `Teleport|Slide` + an ack retail never sends to an
+  ordinary pose, skipping that branch's `ConstrainTo`). Complete Release
+  solution after round 2: **10,856 passed / 4 skipped / 0 failed** — App
+  4,058/3, Bake 15/0, Cli 4/0, Content 124/0, Core.Net 762/0, Core 4,247/1,
+  Headless 79/0, Runtime 1,024/0, UI.Abstractions 543/0.
+  Round 3 closed the conformance reviewer's one remaining blocker: a terminal
+  outcome that never committed now sends the packet's retail position event
+  carrying the body's unchanged pose, because `SmartBox::BlipPlayer`
+  @0x00453940 DISCARDS `CPhysicsObj::SetPositionSimple`'s
+  @0x005162B0 `enum SetPositionError` (other retail callers test it,
+  `== OK_SPE` @0x0055605D) and returns `void`, after which
+  `SmartBox::HandleReceivedPosition` @0x00453FD0 runs
+  `cmdinterp->SendPositionEvent()` @0x00454091 unconditionally and returns
+  @0x0045409D. Retail's rule is: attempt once, do not move on failure,
+  acknowledge regardless, never retry — so route 2 acks exactly once per begun
+  placement, from the commit path or from the settle, never both and never
+  zero.
+  Divergence register: **AD-62 filed** (round 2, rewritten round 3) — the
+  deferred-placement adaptation means a ForcePosition that cannot commit when
+  it arrives, and is then retired without commit, is not re-applied. As of
+  round 3 its position-event ack IS still sent whenever the placement was begun
+  AND that packet's descriptor reaches its own terminal settle. The ack is lost
+  in two narrower groups: where no placement was ever begun (an
+  externally-blocked `Contention`; a re-issue marker that never begins), and —
+  begun but displaced — where a newer force supersedes the packet before its
+  settle, since `SettlePending` nulls `_pending` without reading it (AD-62
+  shape (v)). Replaying that one would emit a stale-sequence report carrying
+  the newer packet's pose; the displacing packet always acks. Retail's
+  `SmartBox::BlipPlayer` is synchronous against a fully resident world and
+  reaches none of these states. The route-2 cutover ITSELF still adds no
+  deviation (it closes the
+  duplicate-authority + premature-ack bug); AP-131 is explicitly NOT retired
+  here (its named legacy `TryApplyPosition` caller is route 4's job, not
+  route 2's).
+- **#286 — OPEN — headless never calls `RetryPending` on its placement
+  projection subscription.** `RuntimePlacementProjectionSubscription.RetryPending`
+  has exactly one caller in the tree, `GraphicalSessionEventRoute.cs:109,113`;
+  `HeadlessSessionEventRoute` constructs the subscription
+  (`HeadlessSessionEventRoute.cs:22`) but nothing pumps its retry. C4 route
+  2's R4 fix deliberately stopped the force-ack from consuming a `Place` the
+  sink declined, on the contract that the subscription's OWN retry re-offers
+  it — so on headless a declined `Place` would sit at the FIFO head and wedge
+  the ordered stream. Latent: not proven reachable today (the headless sink's
+  decline conditions may be unreachable given its bounded collision window).
+  Fix shape: give the headless host the same per-tick retry pump the
+  graphical route has, or prove the decline unreachable and record why.
+  Filed from the C4 route-2 round-2 review (N3).
+- **#287 — OPEN — `RuntimeAcceptedPositionDriveController.Advance` has no
+  reentrancy latch.** Its template `RuntimeFirstEntryDriveController.DriveAll`
+  guards with `_driving` (`RuntimeFirstEntryDriveController.cs:61,130,132,146`);
+  the accepted-position drive does not, even though `Advance` can now re-enter
+  `SubmitAndResolve` through the `SettlePending` re-issue. No live re-entrant
+  path exists today (the funnel's recursion is bounded at one level and every
+  host pumps `Advance` from a single synchronous cadence point). Hygiene, not
+  a live defect. Filed from the C4 route-2 round-2 review (N4).
+- **#288 — OPEN — two side effects were dropped when
+  `HeadlessSessionWorldProjection.BlipLocalPlayer` became
+  `CenterOnAcceptedForcePosition`.** (a) The deleted method also restored
+  `controller.LocalEntityId = record.LocalEntityId ?? 0u`; the replacement
+  (`HeadlessSessionWorldProjection.cs`, `CenterOnAcceptedForcePosition`) does
+  not. Inert today — nothing clears the id between publication and a
+  ForcePosition — but it is an unreplaced deletion, not a decision. (b)
+  `_movementTruthDiagnostics.OnServerEcho` no longer fires for a local
+  ForcePosition on the graphical host, because that route returns before the
+  generic tail (`LiveEntityNetworkUpdateController.cs`). Diagnostic-only.
+  Filed from the C4 route-2 round-2 review (N5).
+- **#289 — OPEN — two doc comments still cite the deleted
+  `PlayerMovementController.BlipPosition`.** `src/AcDream.Core/Physics/Motion/ConstraintManager.cs:25`
+  and `src/AcDream.Core/Physics/PhysicsBody.cs:442` both name it inside `<c>`
+  tags, so they are build-safe (unlike a `<see cref="..."/>`, which R9 already
+  fixed) but false: C4 route 2 deleted the member. Left as-is they become the
+  citation a future session trusts. Filed from the C4 route-2 round-2 review
+  (R9 residue).
+- **#290 — OPEN — route 1's classified `SendPositionImmediately` never fires
+  an ack.** The C4 plan required confirming whether the outbound position ack
+  fires while an initial-Create residence owns the record. It does not:
+  `RuntimeInitialCreateContinuationExecutor` consumes
+  `SendPositionImmediately` only as a trace fact (`:717`, `:2576`), never as
+  an outbound send. Not a regression (route 1 predates route 2 and behaves
+  exactly as before), but retail's FORCE_POSITION branch acks unconditionally
+  after `BlipPlayer`, so a ForcePosition admitted during the login residence
+  window is one retail ack we do not send. Decide at route 4/C5 whether the
+  residence tail should send it. Filed because the plan required filing it.
+- **#291 — OPEN — the headless 3x3 collision window needs a divergence
+  register row.** C4 route 2's R2 fix promoted it to a NAMED member of the
+  Runtime-facing contract (`IRuntimeDirectWorldProjection.CenterOnAcceptedForcePosition`)
+  with an explicit ordering requirement — re-center BEFORE the placement
+  submits — that retail has no analogue for (retail has every landblock
+  resident). No existing row covers it: AD-6 is retired and AD-2 is the
+  graphical reveal barrier. Recommend one AD row naming the window, the
+  ordering requirement, and the symptom if it breaks (a `DeferredCell` park
+  the window can never publish). Filed from the C4 route-2 round-2 review.
+- **#292 — OPEN — C4 route 2 acceptance item 2 is source-pinned, not
+  proven.** Recorded gap from round-2 finding B2 (the plan's own text is
+  corrected at
+  [`2026-08-02-placement-cutover.md`](plans/2026-08-02-placement-cutover.md)).
+  First half — "the generic tail no longer double-writes the local player" —
+  is pinned only by a source-text regex, which a differently spelled second
+  write would pass, and no test exercises the branch. Second half — "the
+  committed projection is what moves the render entity" — is uncovered at any
+  layer: no test drives a route-2 ForcePosition through
+  `RuntimePlacementPresentationSink` / `TryApplyRuntimePlacementPlace` and
+  asserts the `WorldEntity` moved. Given R4, that is exactly the seam whose
+  failure is silent (canonical body moves, render entity stays). Fix shape: an
+  App-layer end-to-end test asserting the render entity's position/cell came
+  from the committed placement receipt.
+- **#293 — OPEN — the DeferredCell park still consumes `Withdraw` receipts the
+  sink may have declined.** `RuntimeAcceptedPositionDriveController.SubmitAndResolve`'s
+  `DeferredCell` branch drains the head of the placement FIFO while it is a
+  `Withdraw` for this entity and calls `AcknowledgeProjection` on it
+  (`RuntimeAcceptedPositionDriveController.cs:709-716`). That is the exact
+  receipt-stealing shape R4 removed for `Place`: the R4 fix's whole argument is
+  that `RuntimePlacementProjectionSubscription` deliberately leaves a receipt
+  the sink declined at the FIFO head for its own later retry, and that this
+  route has no follow-up binding to cover it. The `Withdraw` drain was left
+  unchanged in round 1 because it is copied verbatim from
+  `RuntimeFirstEntryDriveController.TryCompleteContinuationPlacement`, but the
+  same asymmetry applies — that controller's residence guarantees the decline,
+  this one's does not. Fix shape: decide whether a declined `Withdraw` is
+  reachable for this route and either drop the drain (letting the
+  subscription's retry own it, as `Place` now does) or record why the decline
+  cannot happen here. Filed from the C4 route-2 round-3 adversarial review.
+- **#294 — OPEN — the deferred wake reconciles and acks BEFORE the funnel's
+  currency guard.** `RuntimeAcceptedPositionDriveController.Advance` consumes
+  the acknowledged placement and immediately calls `ReconcileAndAcknowledge`
+  (`:452`), and only then enters `SettlePending`, which is where the
+  entity-still-active / still-the-local-player / still-the-same-incarnation
+  checks live (`TryGetActive`, `ServerGuid`, `PhysicsBody`, `key !=
+  terminalToken.Entity`). So a wake that lands after the entity departed the
+  world, stopped being the local player, or released its incarnation still
+  runs the controller-local reconcile and can still send an outbound
+  `AutonomousPosition`. `ReconcileAndAcknowledge`'s own
+  `record.ServerGuid != _localPlayerServerGuid()` test uses the RETAINED
+  record, not a re-resolved active one, so it does not cover the departed
+  case. Ordering, not a workaround: the currency guard belongs before the
+  reconcile. Filed from the C4 route-2 round-3 adversarial review.
+- **#295 — OPEN — the re-issue retry marker inflates
+  `AcceptedPositionDrivePendingCount`.** When `SettlePending`'s re-issue cannot
+  begin, it parks the terminal descriptor as a retry marker in `_pending`. That
+  marker is not an in-flight placement — its token is dead by construction —
+  but `PendingCount` (`:259`) and the ownership ledger registered at `:255-256`
+  both report it as one. Any convergence reader (`CaptureOwnership`,
+  `GameWindowLifetime.DisposeGameRuntime`'s non-convergence throw) therefore
+  sees a placement that does not exist, and a marker that outlives its
+  usefulness reads as a wedged operation rather than as "a re-issue is owed".
+  Fix shape: count in-flight placements and owed re-issues separately, or give
+  the marker its own field. Filed from the C4 route-2 round-3 adversarial
+  review.
+- **#296 — OPEN — a retryable prepare is reported to hosts as `Contention`.**
+  `SubmitAndResolve` returns `RuntimeAcceptedPositionExecutionStatus.Contention`
+  for a retryable preparation status (`RetrySetupUnavailable` /
+  `RetryWorldFrameUnavailable`, `:661`), reusing the status whose documented
+  meaning is "begin failed; the entity already owns an operation". The two are
+  materially different: the retryable case DID begin, IS retained in `_pending`,
+  and WILL be re-driven by the next `Advance` pump, while true `Contention` may
+  have recorded nothing at all (register row AD-62 shape (iv)). Hosts cannot
+  distinguish them — `LiveEntityNetworkUpdateController` branches on the status
+  — and neither can a future reader of the enum doc. Fix shape: a distinct
+  status (or a documented union) so the retained-and-pumping case is not
+  conflated with the dropped case. Filed from the C4 route-2 round-3
+  adversarial review.
+
 ## C3c placement cutover — 2026-08-02
 
 - **#276 — OPEN — SpawnPlacementSettler discards the settle's resolved
@@ -4913,6 +5209,16 @@ gate is `PhysicsBody.IsFullyConstrained` (former TS-35) via
 `jump_is_allowed`. Decomp: `docs/research/2026-07-03-r5-managers/`,
 `docs/research/2026-07-30-constraint-leash-constants.md`.
 
+**2026-08-03 correction (C4 route 2, #285):** the `BlipPosition` half of this
+arming site was an unbacked deviation for the ForcePosition branch
+specifically — `SmartBox::BlipPlayer` (0x00453940), the function
+`HandleReceivedPosition`'s FORCE_POSITION branch calls, is not on the
+"Player, normal" branch this slice modeled; retail's FORCE_POSITION early
+return (0x0045409D) precedes every `ConstrainTo` call. `BlipPosition` is
+deleted; the leash is no longer (re)armed on a ForcePosition. The arming
+site for every OTHER inbound position (remotes, the local player's ordinary
+teleport/`SetPosition`) is unaffected.
+
 **Acceptance:** the two constants are recovered (byte-decoded from the
 binary), acdream arms the leash on inbound server positions,
 `IsFullyConstrained` fires while rubber-banding, and a jump attempt inside