fix: update every element unassigned in the same shadow variable pass

[fodzal]

Issue.
In a SINGLE_DIRECTIONAL_PARENT graph, a pass that unassigns two or more elements only updates the first of
them; the rest keep the value they held while still assigned.

updateChanged() walks each changed element's chain, and skips one that a previous walk already covered:

var key = keyFunction.apply(changedEntity);   // the element's inverse entity
var lastProcessed = keyToLastProcessedObject.get(key);
if (lastProcessed == null || topologicalOrderComparator.compare(lastProcessed, changedEntity) < 0) {
    lastProcessed = updateChanged(changedEntity);
    keyToLastProcessedObject.put(key, lastProcessed);
}

The key is null for every unassigned element, and they all compare equal too (getIndexOrElse defaults to 0) — so the first one walked claims the null key, and every other unassigned element wrongly reads that walk as already covering it, even though a walk starting at an unassigned element never reaches past itself.

[v1, v2, v3] (counts 0, 1, 2), one move unassigning both v2 and v3:

	key	guard	outcome
v2	null	nothing under that key yet	walked, recomputed to null ✓
v3	null	compare(v2, v3) == 0, not < 0	skipped, keeps its stale count of 2

Any move that unassigns 2 or more elements of the same list under one before/after bracket triggers this (for example: SubListUnassignMoveProvider).

Fix.
An unassigned element stands as its own key:

var entityKey = keyFunction.apply(changedEntity);
var key = entityKey != null ? entityKey : changedEntity;

The guard still dedupes the two change events one unassigned element fires (its entity and previous both change) — they share the same object as their key — while no longer pooling different unassigned elements together.

TopologicalSorter.key() was declared non-nullable even though it's getInverseSingleton; the record's Javadoc now says what each component returns for an element in no chain.

Test.
SingleDirectionalParentVariableReferenceGraphTest#elementsUnassignedInTheSamePassAreAllUpdated
It unassigns two of an entity's three elements in one pass, firing both parent-variable changes for each (as a real unassign does), and asserts both lose their count. TestdataCountingValue#countSupplier throws if called twice in the same pass, which pins that the fix doesn't trade a skipped update for a doubled one.

[Christopher-Chianelli]

I would do it a different way to avoid putting useless keys inside the processed object map.

[Christopher-Chianelli]

I wouldn't do this; I would instead do if (key == null) {updateChanged(changedEntity);} else if (...) {} below

[Christopher-Chianelli]

missing afterListVariableElementUnassigned calls for value2 and value3

[triceo]

@fodzal Thanks for the fix! Do you have any plan for when you expect to undraft this?
We have a release coming up and, if possible, we'd like to roll this one in.