Normalized vs Denormalized State: Cache Drift Simulator

Mobile and web apps constantly face the same question that Redux, MobX, StateFlow and LiveData all answer differently: does a screen hold its own copy of a piece of data, or does it read from one shared source of truth? This simulator makes that choice visible. A single tracked entity — a "Post" with a like count — sits in a canonical store; two to five screens observe it. In denormalized mode each screen caches its own copy, and dispatching an update only refreshes the screen that actually re-read the data, leaving the others drifting out of sync with a growing staleness age. Switch to normalized mode and every screen instead references the one canonical record, so an update reaches all of them in the same step and the consistency readout stays pinned at 100%. An "auto-resync on read" toggle shows the usual workaround — periodic refetching — and why it narrows the staleness window without ever closing it.