refactor(runtime): own teleport destination correlation

docs/research/2026-07-15-retail-portal-space-pseudocode.md

@@ -552,6 +552,79 @@ no Marketplace-specific classifier or portal-exit behavior is required.
   consumed even if the channel already advanced. Thus reordered delivery and
   retransmitted notifications cannot materialize the wrong destination or
   strand the transit, while canonical physics retains its own retail gates.
+
+### Runtime F751/Position ownership pseudocode (Slice J6.3)
+
+Named retail `SmartBox::HandlePlayerTeleport @ 0x00452150` compares the
+incoming F751 sequence with the player's current `update_times[4]`
+(`TELEPORT_TS`) using the retail unsigned-16 wrap rule. An older notification
+is rejected. Equality or a newer notification clears
+`position_update_complete` and `has_been_teleported`, then sets
+`waiting_for_teleport`; it does **not** write `update_times[4]`.
+`SmartBox::TeleportPlayer @ 0x00453910` later installs the complete accepted
+`Position` and calls `PlayerPositionUpdated`. ACE corroborates the wire
+transaction: `GameMessagePlayerTeleport` advances ObjectTeleport once, then
+the immediately following UpdatePosition carries that same value. Holtburger
+confirms F751 is only one little-endian `u16` plus alignment.
+
+The Runtime ownership port therefore keeps canonical physics admission and
+transit correlation separate:
+
+```text
+on F751(sequence):
+    reject unless canonical player TELEPORT_TS admits equality/newer
+    reject if this Runtime transit owner already observed sequence or a newer one
+    retire buffered destinations older than sequence
+    end the prior active correlation, retaining wrap-aware history
+    remember sequence as a pending teleport start
+
+when the graphical host can enter portal presentation:
+    promote pending sequence to active sequence
+    if an accepted matching Position was buffered:
+        expose it as the one destination waiting to be aimed
+
+on accepted local-player Position(destination, teleportAdvanced):
+    canonical physics has already admitted and applied the packet
+    if teleportAdvanced:
+        retire buffered destinations older than destination.TeleportSequence
+
+    if active sequence equals destination.TeleportSequence:
+        accept only the first destination
+    else if pending sequence equals destination.TeleportSequence:
+        buffer only the first destination until presentation activates
+    else if teleportAdvanced and the sequence may belong to a future F751:
+        buffer only the first destination
+    else:
+        ignore it for transit correlation
+
+when App aims a destination:
+    Runtime atomically verifies:
+        active teleport
+        exact teleport sequence
+        exact accepted destination cell
+    Runtime creates the one reveal generation and consumes the aim claim
+    App translates the cell-local frame into render space and recenters
+
+before and after App placement:
+    verify the same reveal generation + teleport sequence + destination cell
+    only then acknowledge Runtime materialization
+
+on ordinary portal completion:
+    end active correlation but retain last-F751 history
+
+on session reset:
+    clear pending/active correlation, buffered/accepted destinations,
+    last-F751 history, and the visible reveal snapshot
+    retain the monotonic reveal-generation counter
+```
+
+The Position-before-F751 buffer is not a second position authority. It stores
+only immutable data from a Position already accepted by the canonical Runtime
+physics owner, and exists because host projection availability and ordered
+event delivery can straddle the presentation activation edge. It can neither
+apply physics nor turn an ordinary non-advancing Position into a portal
+destination.
+
 - Destination placement resets the retail chase camera's published and sought
   positions to the player before the normal update path resumes.
   - `RetailLiveFrameCoordinator` owns the `SmartBox::UseTime` phase barrier: