feat: add witnessed knowledge and wind ambience

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 v3 and captures:
+simulation. The current world schema is v5 and captures:
 
 - simulation seed, tick interval, tick count, clock remainder, and elapsed
   clock ticks;
@@ -12,16 +12,20 @@ simulation. The current world schema is v3 and captures:
 - village resource counters;
 - controlled per-NPC wander RNG streams;
 - scene-independent resource state plus the definition facts needed while its
-  ResourceNode is unloaded.
+  ResourceNode is unloaded;
 - pantry contents, carried NPC inventory, the ordered economic event stream,
-  and its next stable event ID.
+  and its next stable event ID;
+- directed relationship records with familiarity, trust, and the stable event
+  ID that last changed trust;
+- per-NPC known-event records that reference objective event history without
+  copying it.
 
 The top-level identity is:
 
 ```json
 {
   "schema": "the_steward.simulation",
-  "schema_version": 3
+  "schema_version": 5
 }
 ```
 
@@ -51,7 +55,8 @@ its future random sequence.
 5. requiring the complete final-state checksums to match.
 
 It also verifies clock remainder, resource amount/reservation/enabled
-round-tripping, presentation unload/rebind, and rejection of unsupported
+round-tripping, presentation unload/rebind, directed relationship/cause
+round-tripping, divergent known-event state, and rejection of unsupported
 schemas.
 
 NPCStateRecord v2 adds the resolved travel destination and whether it is
@@ -71,6 +76,40 @@ stream. Event records use stable source/destination/item IDs, reject invalid or
 duplicate IDs, and preserve deterministic ordering across save/restore. See
 [the economic event stream](ECONOMIC_EVENTS.md).
 
+EconomicEventRecord v2 adds the authoritative world position captured when the
+fact is recorded. Nested v1 events migrate with a zero-vector fallback; old
+saves already encode their stable location IDs, and migrated knowledge is not
+recomputed spatially.
+
+SimulationStateRecord v4 moves social authority into top-level directed
+`RelationshipStateRecord` entries. Each record contains `observer_id`,
+`subject_id`, familiarity, trust, and `last_trust_cause_event_id` (`-1` when no
+event has changed trust). Parsing requires unique ordered pairs, existing NPC
+IDs, bounded relationship values, and a real event for every non-empty cause
+ID.
+The relationship system serializes records in stable observer/subject order so
+they participate in deterministic checksums.
+
+World schema v3 migrates its NPC-local familiarity pairs into directed
+relationships with neutral trust. Nested NPC schema v4 removes that obsolete
+duplicate field; v3 NPC records remain accepted only through the explicit
+migration. World schemas v1–v2 also derive the graph from any legacy
+familiarity data (or initialize it empty) after their storage/event migrations.
+
+SimulationStateRecord v5 adds top-level `KnownEventStateRecord` entries keyed
+by `knower_id` and `event_id`. The objective `EconomicEventRecord` remains the
+single completed fact; knowledge records only state which NPC knows it. Parsing
+requires unique NPC/event pairs and valid references to both an existing NPC
+and an event in the same record. A relationship's causal event must also be
+known by that relationship's observer and, for the current trust contract, be
+a food deposit performed by the relationship subject.
+
+World schema v4 migrates relationship causes into known-event records. The old
+schema used village-wide awareness, so this preserves the implied known fact
+without falsely inventing spatial witness provenance. New v5 facts are created
+only at event-record time from the actor and nearby NPC positions; historical
+events are never re-evaluated against current positions.
+
 ## Resource authority
 
 `SimulationManager` owns `ResourceStateRecord` instances independently of the
@@ -106,8 +145,11 @@ visuals from authoritative state.
 This phase does not yet provide:
 
 - a save-slot menu, metadata, thumbnails, autosaves, or multiple profiles;
-- migrations older than the explicitly supported world schemas v1 and v2;
-- player inventory, relationship, schedule, or social-memory records;
+- migrations from any historical world schema other than the explicitly
+  supported v1–v4 layouts;
+- player inventory or player relationship records;
+- broader relationship dimensions, line-of-sight/hearing evidence,
+  acquisition provenance, memory decay, or communication;
 - persistence for the player transform or presentation-only scene state.
 
 Those features should build on this boundary rather than inventing parallel