fix: evaluate conditions against tick-start state (order independence)

[zntznt]

Closes the last open item from the codebase review: activator and connection conditions read live pool values while pulls, gates, and converters mutate mid-tick, so a step's result could depend on node storage order, contradicting CONCEPTS.md section 1.

Semantics (hybrid synchronous)

• doStep snapshots every node's state value before the fire phase; activator checks (_nodeEnabled) and source-value connection conditions (_connFires) read the snapshot through a single seam, _condValueOf
• Trigger and reverse-trigger cascades keep live reads (queue entries carry a live flag): a cascade is a causal reaction within the step whose order comes from the graph, not storage, so live reads there are deterministic and intentional
• Registers in conditions read their previous settled value, consistent with the existing one-step variable lag; variable-mode conditions were already lagged and are untouched
• Movement is untouched: rates, fair allocation, capacity clamps, and the atomic push commit still read live state, so conservation cannot break
• New CONCEPTS.md subsection documents the rule and the cascade exception

Evidence

• 197 tests green (194 + 3 new); every new test verified to FAIL against the pre-fix engine via stash:
  • the original repro in both insertion orders produces identical, tick-start-correct traces
  • permutation property: identity / reversed / rotated node storage orders give byte-identical 25-step seeded traces
  • cascade exception: a trigger-fired node acts on live mid-step state while a snapshot-checked contrast node does not
• All 11 built-in demos traced 300 seeded steps pre vs post: byte-identical. Not vacuous (the demos lean on activators and conditions heavily); their condition sources only change at the atomic commit or in variables, so tick-start and live reads coincide for them. No shipped behavior changes.