Let actions write per-player state: mutable state cells and stored modifiers (Set Ultimate Charge and class) #116

Problem

After #113, Bastion on athena main with the committed docs/scenario-examples/valid/bastion.json runs 19 ticks and ends not_modeled:

{ "status": "not_modeled", "construct": "action setUltCharge", "tick": 19,
  "location": { "rule": 233, "name": "[Player] Display skip ready", "eventPlayer": "p2", "action": 8 } }

The #104 PR body lists 61 actions that stay not_modeled because they change something a program can read. Version-2 player state (state_reads.rs, STATE_READS) already answers reads of those values from the scenario, as constants. Actions that write those values have nothing to write to. Fixing one action per cycle would take about 35 cycles, so this issue designs the mechanism once and applies it to the whole class of per-player writes.

Design

Give each scenario player a mutable state cell per state key, seeded from the scenario state map (or still missing_input when the key is absent and the program reads it before any write). Actions write the cell; reads return the cell's current value. The mechanism must:

• keep the scenario input contract unchanged (absent key stays missing_input; a program that writes a key before reading it does not need the scenario to supply it, and the write defines the value);
• make every write visible in changes/the trace like a variable write, so the viewer shows ultCharge, health, isDead, … changing per tick (name them by the state key and player id);
• not simulate gameplay effects: no damage, healing, movement or physics follows from a write.

Classify each of the 61 actions in the #104 PR body, per action and with the catalog description as evidence (do not group by name):

1. Direct write to a modeled read (for example Set Ultimate Charge to ultCharge, Set Health/Set Max Health, Kill/Respawn/Resurrect to isDead with whatever the catalog says about health): write the cell.
2. Stored modifier with no in-model reader (for example Set Ultimate Ability Enabled, Set Ability 1/2 Enabled, Set Move Speed, Set Gravity, Set Knockback Received, Set Damage Dealt/Received, Set Healing Dealt/Received, Start Forcing Hero/Stop Forcing Current Hero/Set Allowed Heroes, Start Forcing Spawn Room): record the modifier on the player as an observable effect in the trace (action, player, evaluated arguments), run as an action that changes no readable value. Check first that no value Bastion reads depends on it (for example Is Button Held and Throttle Of depend on the button and throttle forcing actions: those need their own decision, so classify them as 3).
3. Changes a read or the schedule in a way the cells do not capture (entity existence, text ids, roster, match clock, position/velocity forcing, over-time effects, button forcing, Chase): keep not_modeled and list each in the PR body with the reader it would affect and what model it needs, so one follow-up issue per family can follow.

If the catalog text does not settle a case, use class 3. Record the class 1 and 2 choices in docs/findings.md as modeled, not measured.

Scope

• Implementation of the cells, the action classes 1 and 2, and the trace output.
• Docs: docs/scenario-format.md (a write defines a key before any read), docs/simulator-interface.md, docs/findings.md, schema/trace format docs.

Acceptance

• Tests: per mechanism (write then read yields the new value; read before write without a scenario key is missing_input; write visible in changes with player and key); one test per class 2 action showing it appears as an effect and changes no read; class 3 actions still stop not_modeled.
• Bastion rerun with the committed bastion.json unchanged except what this PR adds: report the new first stop, or completion, and the remaining class 3 list grouped by family with the readers each affects. Parent: Run Bastion to completion on athena-sim #45.