Incremental evaluation

The runtime commits to incremental (Salsa-style) computation at two layers. A compile-time layer, keyed on the immutable .oxbin, memoizes Module-only work (parse / resolve / type-check / classify-tier / compile-rule) once per loaded Module and shares it across Stores. A runtime layer, one per (tenant, fork), memoizes every query whose dependency set touches the event log (extent, iof closure, rule fixpoint); a mutate bumps a per-Store generation counter and the engine invalidates exactly the downstream queries.

The load-bearing invariant: for any tracked query, the same (module, store generation, query args) yields the same result. The backend MUST guarantee the generation bump after a successful mutate is atomic and monotonic — no thread observes the increment before the mutation is durable (for Postgres, the bump is in the same transaction as the event insert; for in-memory, a write-lock spans the index update and the increment). Per-(tenant, fork) keying — not per-tenant — is what keeps a mutation on fork A from invalidating warm queries on fork B.