Provide a deterministic map collection in core instead of ad-hoc sorted iteration

[gmliao]

Background

During the replay-scale-fp-perturbation experiment (PR #47), 28/30 recordings initially failed replay verification. Root cause: Swift Dictionary iteration order is nondeterministic (per-process hash seeding; we even observed divergence between two runs in the same process). Any game logic that iterates state.players / state.monsters / state.turrets directly gets a nondeterministic system-update order, which breaks tick-hash equality between live and replay runs.

Current state (workaround, Examples-level)

HeroDefenseLand tick handler and CombatSystem.findNearestMonsterInRange now iterate keys.sorted() and use a lowest-id tie-break. After the fix, 41/41 recordings replay with 0 mismatches. But this is convention, not enforcement — the next dictionary loop someone writes silently reintroduces the bug.

Proposal

The library should own this guarantee rather than relying on every game author remembering it:

• A deterministic keyed collection for state trees (e.g. StateTable<Key, Value>) whose iteration order is defined (sorted keys or insertion order with deterministic storage), usable inside @StateNodeBuilder nodes.
• Optionally: a macro-level warning when a Dictionary stored property is declared in a synced state node, pointing at the deterministic alternative.

Notes

• This is a Sources/ change → goes through the sst-core-change flow, own PR.
• Design should be discussed with the co-author first: it touches the determinism contract (§3, δ semantics) of the paper's model, and the collection's ordering guarantee should match what the paper claims.
• Related: Append cross-architecture verification results to replay-scale-fp-perturbation #48 (cross-arch verification of the same experiment), the CI determinism gate follow-up.