We have other safeties which mean that this is not an issue during
gameplay, but in the new `TestSceneHUDOverlayRulesetLayouts` it became
apparent that allowing this to fallback (via `null` return) could lead
to weirdness.
As time goes on, default skin layouts are getting more and more
complicated because of per-ruleset overrides. This was already sort of
apparent in https://github.com/ppy/osu/pull/31527, and I'm about to make
it worse, so before I do, this is a test scene that is supposed to make
it easier to check all possible combinations at a glance.
I'm not sure why this condition was written this obtusely, but
importantly it was also wrong. It fires when the selection contains
multiple items and only some are removed from it, like when
ctrl-click-unselecting an item from a multiple selection.
Closes https://github.com/ppy/osu/issues/32920.
I don't know if there's going to be other cases of breakage, but from
what I can tell these settings *not* showing infinite precision
representations was a bug with the previous implementation of number
formatting.
The rationale for this change is that the return value was mostly
useless, and at worst, misleading.
When using `LeaderboardManager`, it's assumed that a consumer will bind
to the global `Scores` list to ensure they receive updates for things
like local score changes via the internal realm subscription. If one
decides to instead use the return value of the task, it will be a static
snapshot that potentially becomes stale in the future.
I fell into this trap when refactoring the new leaderboard component
(while attempting to assert correctness that the values we are
displaying were in fact from the fetch operation we requested).
In the interest of keeping things simple, removing the return value
seems to be the best path forward.