docs: record combat, wolves, factions, and tribe war systems

docs/SIMULATION_STATE_SCHEMA.md

@@ -3,7 +3,7 @@
 ## Current contract
 
 `SimulationStateRecord` is the versioned JSON boundary for the current
-simulation. The current world schema is v13 and captures:
+simulation. The current world schema is v14 and captures:
 
 - simulation seed, tick interval, tick count, clock remainder, and elapsed
   clock ticks;
@@ -28,14 +28,18 @@ simulation. The current world schema is v13 and captures:
   deterministic invalidation reason and close tick;
 - a player record holding the player-citizen's hunger, energy, and carried
   inventory. The player's world position remains presentation-owned and is
-  intentionally not serialized.
+  intentionally not serialized;
+- combatant records (health, weapon, faction, position, hostility) for NPC
+  defenders and standalone raiders/wolves;
+- faction records (food, warriors, aggression, morale, stance, war plan) for
+  the village and the hill tribe.
 
 The top-level identity is:
 
 ```json
 {
   "schema": "the_steward.simulation",
-  "schema_version": 13
+  "schema_version": 14
 }
 ```
 
@@ -233,6 +237,17 @@ stable. Resource records also migrate to v4, adding `max_amount` and
 `regrow_rate`; legacy v3 resources keep their current amount as the cap and
 gain no regrowth.
 
+SimulationStateRecord v14 adds the top-level `combatants` and `factions`
+arrays. `CombatantStateRecord` v1 tracks health, equipped weapon, faction,
+hostile flag, and position for NPC defenders, tribe raiders, and wolves.
+`FactionStateRecord` v1 tracks food, warriors, aggression, morale, stance, and
+the tribe's war plan with its confidence. World schemas v13 and earlier migrate
+to empty combatant lists plus default village/tribe factions; the manager
+registers living NPC combatants on restore. Combatant positions are quantized
+to a binary-exact grid and faction food to a binary-exact step so that
+arbitrary world floats round-trip through JSON without breaking deterministic
+continuation checksums.
+
 Current-schema parsing requires unique animal IDs that do not collide with
 resource or storage IDs. An animal reservation must belong to an existing NPC
 whose active feed task targets that exact animal. Every `animal_fed` event