Working about pathfinding

WEBSOCKET_NETWORKING.md

@@ -75,15 +75,15 @@ When `NETWORK` is defined:
 
 The WebSocket client is created only when `battle_zone_multiplayer` is selected
 and is destroyed when that campaign is unloaded. The single-player and
-multiplayer Battle Zone entries share location content and the start-state path,
-so the state can be regenerated through the single-player entry. At startup, the
-standalone server loads the authoritative half of that shared save and rewrites
-its campaign ID to `battle_zone_multiplayer`; each remote client restores only
-the local presentation half. The multiplayer campaign currently declares the
+multiplayer Battle Zone entries share location content but use separate
+start-state files. At startup, the standalone server loads the multiplayer
+start state; each remote client restores the received authoritative state and
+its own local presentation state. The multiplayer campaign currently declares the
 pre-existing `player` and `player2` state entries as connection
 slots; the random test-bot controller is disabled.
-The campaign's `networkCompatibility` token is the fingerprint; release builds
-must bump it whenever deterministic content changes.
+The campaign's `networkCompatibility` token is the fingerprint (currently
+`battle-zone-lockstep-v5`); release builds must bump it whenever deterministic
+content changes.
 
 If DNS resolution, TCP connection, the WebSocket handshake, or the active socket
 fails, the client unloads the remote campaign and returns to the campaign
@@ -180,6 +180,16 @@ submission, and contiguous tick consumption.
 
 ## Current Limitations
 
+- Paths are calculated independently on every lockstep participant from the
+  same ordered commands and tick-start occupancy. Integer A* costs, stable
+  character IDs, serialized previous-tick movement and blocked/retry state, and deterministic
+  nearest-reachable ties keep route selection aligned.
+- Moving characters are omitted from A* but remain solid to the authoritative
+  movement guard. After three blocked ticks, players/bots cancel movement while
+  NPCs stop and consume the next serialized cooldown from their deterministic
+  retry sequence before replanning around the blocker.
+- Opposing traffic can wait in a one-character-wide corridor because the
+  current policy does not reserve future space-time cells.
 - Only preconfigured player slots can connect; dynamic join/spawn commands are
   not implemented.
 - There is no authentication or reconnect/replay history.