Closes#25663 (again).
As it turns out, in some scenarios it can be the case that the current
game-global `Beatmap` is not valid for the current game-global
`Ruleset`. The validity of one and the other in conjunction is only
really validated by the song select screen; elsewhere there is no
guarantee that the global beatmap is playable using the global ruleset.
However, this only comes up in very specific circumstances, namely one:
when trying to autoplay a catch beatmap with osu! ruleset globally
active via the skin editor flow.
`Player` is responsible for retrieving the beatmap to be played. It does
so by invoking the appropriate beatmap converter and asking it if the
beatmap can be converted:
6d64538d7a/osu.Game/Beatmaps/WorkingBeatmap.cs (L262-L266)
If the code above throws, `Player` actually silently covers for this, by
trying the beatmap's default ruleset instead:
6d64538d7a/osu.Game/Screens/Play/Player.cs (L529-L536)
However, for the pairing of osu! ruleset and catch beatmap, this fails,
as `OsuBeatmapConverter`'s condition necessary for permitting conversion
is that the objects have a defined position:
6d64538d7a/osu.Game.Rulesets.Osu/Beatmaps/OsuBeatmapConverter.cs (L25)
which they will do, due to the fact that all catch beatmaps are really
just osu! beatmaps but with conversion steps applied, and thus `Player`
succeeds to load the catch beatmap in osu! ruleset.
In the skin editor scenario, this would lead to the secondary failure
of the skin editor trying to apply `CatchModAutoplay` on top of all
of that, which would fail at the hard-cast of the beatmap
to `CatchBeatmap`.
This also moves the beatmap skin disable toggle to on toggle, in line
with review feedback.
I've decided to always apply the disable, not just on the `Player`
screen. It should be assumed that if a user is in the skin editor they
are never going to need access to this anyway.
