ORMapEntry

An entry of an ORMap: the key's presence tags, each carrying the value that was written under it. The key's observable value is the join of every tag's contribution; the tags are the observed-remove handle for the key.

Why the value hangs off the dots and not off the entry (#2086). The obvious shape — one tag set plus one value beside it — is not a join-semilattice. An entry has exactly one value slot, so a join that keeps two operands' contributions must blend them into that slot, and no later join can tell them apart again. Retire one of the two tags afterwards and the blend keeps the contribution the tag was carrying, so the result depends on the order the operands were joined in. That is not a bug in any one line: any entry-level value has it, because the value stops being a function of which dots are live. Attaching each write to the dot that made it restores the correspondence — a contribution survives exactly as long as its tag does — and the join becomes the same causal filter DotSet already uses, which is associative.

Invariant: a dot names one write. contributions maps a dot to the value written under it, and a dot is minted once, so wherever it appears it carries the same value. join still folds the two sides with Quilted.piece rather than picking one, so a violation degrades to a merge instead of a silent asymmetry between a ⊔ b and b ⊔ a.