This will trigger a change even if nothing happens. But I think that's
okay (not easy to avoid) because the change handler should be aware that
nothing changed, if anything.
Closes https://github.com/ppy/osu/issues/24065.
The buttons don't check whether the operation they correspond to is
possible to perform in the current state of the selection box, so not
checking `Can{Reverse,Rotate}` causes superfluous undo states to be
added without any real changes if an attempt is made to reverse or
rotate a selection that cannot be reversed or rotated.
The code here was assuming that if the beatmap which is having changes
copied across does not exist within the `BeatmapSet.Beatmaps` list, it
was not yet persisted to realm.
In some edge case, it can happen that the beatmap *is* persisted to
realm but not correctly attached to the beatmap set. I don't yet know
how this occurs, but it has caused loss of data for at least two users.
The fix here is to check realm-wide for the beatmap (using its primary
key) rather than only in the list. We then handle the scenario where the
beatmap needs to be reattached to the set as a seprate step.
---
This does raise others questions like "are we even structuring this
correctly? couldn't a single beatmap exist in two different sets?"
Maybe, but let's deal with that if/when it comes up.