fix(physics): C4 route 3 — portal placement authority (local player)

Removes a duplicate placement authority for local-player portal arrival.
Portalling worked before this change and works after it — this is not a
bug fix, EXCEPT that it found and fixed one dead-code production bug.

THE PRODUCTION BUG: TryExecuteCanonicalPortalPlacement re-read the
accepted destination at Place time, but TryBeginPortalReveal already
consumes that slot at Aim time — so the arm was 100% dead code and every
real portal Place refused with host-token-unavailable. Found only
because we refused to accept 7 skipped tests instead of chasing the
count to zero.

RETAIL IS THE GENERIC PATH FOR THE THIRD ROUTE RUNNING:
SmartBox::TeleportPlayer @0x00453910 = SetPositionSimple(dest, 1) with
flags 0x1012, followed by PlayerPositionUpdated.

BOTH INVERSIONS, WITH THEIR ANCHORS: unlike route 2, the leash IS armed
here (ConstrainTo @0x0045418A) and velocity is zeroed
(set_velocity @0x004541B4); unlike route 4b-3, the local teleport_hook
runs AFTER placement (@0x004538AE).

THE THREE-ROUND DEFECT CHAIN, HONESTLY:
- Round 1 released the player at the pre-teleport position while the
  anim stream marched on — the contract wrongly assumed Place re-fires
  (process rule 1's third occurrence this campaign).
- Round 2's fix inferred commit from a global PendingCount, which three
  non-committing paths also clear — making the SAME bug complete
  cleanly and silently. Strictly worse than round 1: round 1 at least
  tripped portal-complete-before-materialized.
- Round 3 latches the commit where it actually happens
  (ReconcileAndAcknowledgePortal), keyed on reveal generation and
  teleport sequence, via TryConsumePortalCommit. Two of the three
  required regression tests landed and are sabotage-verified on both
  hosts (ParkedPlace_ForgottenByOrdinaryMergeDoesNotLatchAsCommitted /
  HeadlessPortalPrepareDestinationForgottenByOrdinaryMergeDoesNotLatchAsCommitted).
  The third (force-arm-takes-the-slot) was judged unnecessary on review:
  with the inference gone, PendingCount is only a "don't ask yet" guard
  at both gates, so a force operation occupying or vacating the slot no
  longer changes an input the commit decision reads — the case collapses
  into what the landed test already discriminates.

THE B2/P3 RESOLUTION: both round-2 reviews were right about different
branches of the same synchronous call. RuntimePlacementProjectionSubscription
.OnPlacement acknowledges the FIFO head only when TryApply returns true;
a Place whose portal authority went stale (transit ended/superseded
while parked) used to return false, wedging every later entity's
placement receipt behind it forever. Both sinks
(RuntimePlacementPresentationSink, HeadlessRuntimePlacementProjectionSink)
now acknowledge-and-ignore a stale-authority Place instead of refusing
it. The regression test (RuntimePlacementPresentationSinkTests
.PortalPlace_StaleTransitHostOrSequenceIsAcknowledgedAndIgnored) had
been asserting the old, wrong `false` behaviour; it now asserts and
sabotage-verifies the fix.

Also lands: AP-144 (register discipline — the portal movement-event
send reuses the stricter UsePositionFromServer gate where retail's
SendMovementEvent is the looser autonomy_level != 0 test, diverging
only at level 1, currently unreachable), AP-145 + issue #318 (the
local-player collision-shadow presentation write bypasses its own
publisher's ShadowObjects write via a direct cache .Set(), self-healing
only once dedup diverges — filed, not fixed, pending a composition
test), AD-42 deleted (its last citation retired by the canonical portal
arm), AD-2 updated (the wait-cue's trigger predicate now covers a
second cause), and two documentation corrections: the enter_world
misattribution (both call sites are in SmartBox::HandleCreateObject,
only one in the player branch — portal arrival is TeleportPlayer, not
enter_world) and the stale "local player never reaches this path"
comment on the generic-remote-render-pose write.

Suite: 11,090 passed / 4 skipped / 0 failed. No new skips, nothing
weakened.

STILL OWED: the connected two-client gate, with
ACDREAM_PROBE_LOCAL_TELEPORT=1, scored only if [local-tp] lines
actually appear in the capture — and explicitly NOT scored as covering
issue #318 (no composition test yet asserts PhysicsEngine.ShadowObjects
directly).

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

docs/plans/2026-08-02-placement-cutover.md

@@ -91,6 +91,34 @@ same commit) → docs/handoff commit. No workarounds; no fused slices.
   and local-player owners.
 - `RuntimePortalPlacementAuthority` has zero producing call sites; the
   adapter from `RuntimeWorldTransitState` does not exist.
+  **Corrected 2026-08-04 (C4 route 3 closure,
+  `docs/research/2026-08-04-c4-route-3-contract.md`), itself corrected
+  2026-08-05 (A10 architecture review — the first correction asserted a
+  false fact of its own), and rewritten 2026-08-05 (N5 retail-review
+  round-3 fix — the prior wording of this correction contradicted
+  itself).** The original bullet conflated two separate claims into one
+  sentence, and only one of them was true. What pre-dated route 3 and WAS
+  accurate: the `RuntimePortalPlacementAuthority` type existed (referenced
+  by route 2's `Pending.Portal` field, always `Present: false`), its
+  `IsValid` check existed, and the sinks' portal-authority gates plus
+  `BeginAcceptedPlacementCore`'s gate already read it. What was NOT
+  accurate, and is what "zero producing call sites; the adapter does not
+  exist" actually described: the PRODUCER half — nothing built a
+  `Present: true` authority and called the consumer arm
+  (`RuntimeAcceptedPositionDriveController.TryExecuteAcceptedPortalArrival`/
+  `SubmitAndResolvePortal`/`ClassifyPortalArrival`) — that consumer arm
+  ALSO did not exist before route 3. Route 3 added the producer and the
+  consumer together, in the same slice: the producer is
+  `LocalPlayerTeleportController.TryExecuteCanonicalPortalPlacement` (now
+  `TryAdvancePortalCommit`/`TryExecuteCanonicalPortalPlacementCore`, per the
+  2026-08-05 A1 review fix), which builds the authority from
+  `WorldRevealCoordinator`/`RuntimeWorldTransitState` facts and calls
+  `TryExecuteAcceptedPortalArrival`; the identical Runtime entry point is
+  shared by the headless host. So: the type/`IsValid`/consumer-gate facts
+  pre-dated route 3 and were true before it; the arm (both the producer
+  that builds a live authority and the consumer that reads one) did not
+  exist before route 3 and is what the original bullet's "zero producing
+  call sites" language was pointing at.
 - The exact-Setup mover chain (`PrepareMover` /
   `RuntimeSetPositionMoverPreparer.TryBuild` /
   `IPreparedCollisionSource.ReadSetupCollision`) exists piecewise, unwired.