Added battles in networking

WEBSOCKET_NETWORKING.md

@@ -5,10 +5,13 @@
 The Windows WebSocket transport uses Boost.Asio and Boost.Beast to run a
 server-sequenced deterministic lockstep simulation. A client receives one
 authoritative state at a completed tick boundary. After that, the server sends
-	only numbered tick messages containing ordered destination and presence
-	commands (or an empty command list).
+	only numbered tick messages containing ordered destination, combat-intent,
+	and presence commands (or an empty command list).
 
-Client intent is intentionally limited to `SetCharacterDestinationCommand`.
+Client intent is intentionally limited to
+`SetCharacterDestinationCommand`, `SetCharacterTargetCommand`,
+`ClearCharacterAttackTargetCommand`, and
+`TryCharacterAttackComboCommand`.
 The server also sends `SetCharacterEnabledCommand` in tick bundles when a
 configured player slot connects or disconnects.
 
@@ -27,9 +30,10 @@ configured player slot connects or disconnects.
   the newly connected client.
 - The initial message contains the state, completed snapshot tick, assigned
   player ID, tick duration, two-tick input delay, and compatibility fingerprint.
-- Destination inputs cross from the Asio thread through a queue. The simulation
-  thread validates client sequence numbers, replaces client identity with the
-  assigned slot, and schedules commands two ticks in the future.
+- Destination and character-action inputs cross from the Asio thread through a
+  queue. The simulation thread validates client sequence numbers, replaces
+  client identity with the assigned slot, and schedules commands two ticks in
+  the future.
 - Every tick is broadcast, including ticks with no commands. No periodic state
   snapshots are sent.
 
@@ -44,8 +48,8 @@ configured player slot connects or disconnects.
   consumers and transitional runtime-state bindings continue to work.
 - Camera orientation lives in host-owned `LocationLocalState`, so incoming
   authoritative snapshots cannot overwrite camera movement.
-- `submit()` serializes destination intent only. Other command variants remain
-  local no-ops for a remote connection.
+- `submit()` serializes destination and tagged character-action intent. Other
+  command variants remain local no-ops for a remote connection.
 - Tick bundles are buffered by ID. The replica advances only while the next
   contiguous tick is available, applying its commands before one exact 100 ms
   simulation step.
@@ -106,13 +110,19 @@ Message types are:
 - `initial_state` (server to client): one state snapshot and lockstep metadata;
 - `destination_input` (client to server): monotonic client sequence and a
   centimetre-normalized finite target;
-- `tick` (server to client): tick ID, globally sequenced destination and
-  character-presence commands, and post-tick diagnostic state hash;
+- `character_action` (client to server): monotonic client sequence, an action
+  tag (`set_target`, `clear_attack_target`, or `try_attack_combo`), and a
+  target ID for `set_target`;
+- `tick` (server to client): tick ID, globally sequenced destination,
+  character-action, and character-presence commands, and post-tick diagnostic
+  state hash;
 - `error` (server to client): invalid input, incompatibility, or full server.
 
 Protocol v1 is not compatible. Malformed payloads, non-finite or out-of-range
-coordinates, duplicate client sequences, and unsupported commands cannot enter
-the authoritative command stream.
+coordinates, duplicate client sequences, empty action IDs, and unsupported
+commands cannot enter the authoritative command stream. The server derives the
+location and player character from the assigned connection slot; clients cannot
+use these actions to control another player or an NPC.
 
 WebSocket ordering is not used as simulation time. Integer tick IDs are the
 only authoritative clock. The server uses `steady_clock` only to pace its loop,