docs: fix flow

Author: ox-harris

site/engineering/realtime-engine.md

@@ -9,7 +9,7 @@
 
 The Realtime Engine is the core of LinkedQL’s [live queries](/capabilities/live-queries). It is **an *in-memory* compute + cache layer** that sits between storage and application code, responsible for converting storage-level mutations — WAL, binlog, or in-memory emitters — into logical change streams that materialize as live result sets.
 
-Most existing “live query” approaches are either non-SQL in design or narrow in implementation scope. The live query model enabled by PGLite, for example, requires a local-first database architecture, where a local database replicates a portion of an upstream database and serves as the execution context for live queries. This is a valid and effective strategy, but the special deployment topology requirement effectively becomes a new architectural limitation, and live queries become a feature of a _local database_, rather than of SQL databases in general.
+Most existing “live query” approaches are either non-SQL in design or narrow in implementation scope. The live query model enabled by PGLite, for example, requires a local-first database architecture, where a local database replicates a portion of an upstream database and serves as the execution context for live queries. This is a valid and effective strategy, but the special topology requirement effectively becomes a new architectural limitation, and live queries become a feature of a _local database_, rather than of SQL databases in general.
 
 LinkedQL’s goal is to make reactivity a universal concept across SQL databases — from mainstream PostgreSQL and MySQL/MariaDB, to local and in-memory databases. This requires a design that operates within the strict replication semantics of mainstream databases, accounts for network latency, and manages the compute and resource constraints of these systems. This architectural stance is one key differentiator of the LinkedQL realtime engine.