fix stale size in AbstractMapMultiSet view iterator remove

[rootvector2]

AbstractMapMultiSet's uniqueSet() and entrySet() view iterators drop the whole entry from the backing map but never decrement the cached size field, so removing an element with N copies through either view leaves size() == N while isEmpty() is true and toArray() (sized by size()) returns N trailing nulls.

UniqueSetIterator.remove() calls super.remove() (which deletes the key) and then parent.remove(lastElement, count), but that call short-circuits at map.get(...) == null and never adjusts size; EntrySetIterator.remove() calls decorated.remove() and never touches size at all. Both overrides now subtract the removed entry count from size and bump modCount, matching the size-correct AbstractMapBag.BagIterator and remove(Object, int). Found by comparing the two map-backed count collections. HashMultiSet and TreeMultiSet inherit the fix.

Repro before the patch:

MultiSet<String> ms = new HashMultiSet<>();
ms.add("a", 3);
Iterator<String> it = ms.uniqueSet().iterator();
it.next();
it.remove();
ms.size();    // 3  (expected 0)
ms.toArray(); // [null, null, null]

• Read the contribution guidelines for this project.
• Read the ASF Generative Tooling Guidance if you use Artificial Intelligence (AI).
• I used AI to create any part of, or all of, this pull request. Which AI tool was used to create this pull request, and to what extent did it contribute?
• Run a successful build using the default Maven goal with mvn; that's mvn on the command line by itself.
• Write unit tests that match behavioral changes, where the tests fail if the changes to the runtime are not applied. This may not always be possible, but it is a best practice.
• Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
• Each commit in the pull request should have a meaningful subject line and body. Note that a maintainer may squash commits during the merge process.