A read-only memory wrapped so that the one extraction path can serve ROMs and RAMs alike.

How many words were non-zero at the end of `step`. Only diagnostics and tests want the exact number; the display wants `liveCountExceeds`.

Whether more than `limit` words were non-zero at the end of `step`. This is all the RAM table needs: it chooses between listing every non-zero location and a windowed display, and the exact figure never appears. Asking the cheaper question means the walk stops as soon as the answer is settled, and usually it never starts - a memory that has never had more than `limit` addresses written cannot have more than `limit` non-zero.

Build the store for one read/write memory. `window` is the simulation's `MaxArraySize`: the number of past steps that can still be asked about.

The four combinations the evaluators need, named as the `Memory1` versions they replace so that the call sites read the same.

Current contents at `addr`, on the bigint-value path. A store keeps values in one of two forms, chosen once by word width, and the caller has to ask for the one it holds - the evaluators do, via `BigIntState`. Asking for the other would otherwise read an array that was never filled, so it is redirected rather than trusted.

Current contents at `addr`, on the uint32 path. One array index in the dense case, which is the case every RAM a design can actually simulate falls into.

Put the memory back to the contents it was built with, discarding all history. Called when a simulation restarts, which is the one thing the old representation got wrong: it read the state left by the wrapped-out end of the previous run instead.

The non-zero locations at the end of `step`, in address order - or None when there are more than `limit` of them. This is what a RAM table's sparse display is: every location worth a row, when there are few enough to list. It replaces asking `liveCountExceeds` and then building the answer with `toMemory`, which is the right question answered the expensive way - the count is bounded by the limit but the whole-memory read is not, so a memory with 65,536 addresses written and fifty non-zero now took the sparse branch and paid 80 ms for it, on every render. Bounded by TWO things, and it needs both. The slot table is the set of addresses that could be non-zero - a slot exists once an address has been written, and `reset` seeds the initial contents as writes at step -1 - so the walk stops at the first `limit + 1` non-zero words. But a memory with 65,536 addresses written and fifty non-zero now would run out of SLOTS before it ran out of limit, and walking all of them is the 80 ms read this exists to avoid. So a memory with more than `Constants.maxSlotsForWholeRead` addresses ever written answers None without walking at all: the caller shows a window instead. The count that decides it is therefore addresses EVER WRITTEN, not words currently non-zero. It has to be: the second is what the walk is for, so it cannot also be its precondition.

The whole memory as of `step`, as the immutable type the rest of Issie uses. Only for the places that genuinely want all of it - a memory diff, a golden file - never per render.

The whole memory as of `step`, when reading it is affordable - None when it is not. What "affordable" means, and why it is a count of addresses ever written rather than of words held, is on `Constants.maxSlotsForWholeRead`. A caller told None must show something bounded instead, and must not fall back to `toMemory`.

What one address held at the end of `step`.

Record a write, unless it changes nothing. A write of the value already at that address is not a write: skipping it costs one comparison on a value the reducer has already read (it is the old contents, which a RAM returns as its output) and saves an entry, which every later search and every later compaction then does not have to walk. Nothing observable changes - the contents are identical by definition, and the RAM table's read/write highlighting comes from the input step arrays rather than from here.