This would cause things to look completely out of whack.
The numbers here match `DrawSizePreservingFillContainer` defaults as
used by `OsuGameBase.CreateScalingContainer()`.
While a mod-created replay did flag itself as performed by a bot, the extension method converting it into a Score did not copy all the generated properties.
As noted, it might be preferable for ModCreatedUser to inherit APIUser and forward it as-is to the Score instance.
Related to PR #24675
The mod generally will only be present on scores imported from stable.
As such, it's probably ok to mark it as such.
The primary reason for this change is to address #24436 (Score V2 being
visible on beatmap overlay leaderboard mod selector).
There is one possibly-unintended consequence of this change, namely that
the results screen uses `UserPlayable` to determine as to whether
animations should be played back, with the intention of turning off the
animation playback for autoplay scores specifically. Therefore, turning
off this flag will mean that the results screen animations will not play
out for Score V2 scores - but I tend to consider this as either largely
unimportant, or something that should be fixed in some other way
(possibly by checking against the autoplay mod directly).
Other usages of `UserPlayable` are either innocuous, or straight-up good
safeties going forward in the context of Score V2 (guards against
selection in mod select overlays, against score submission with
the mod).
For some reason this started flaring up recently all over for me and
showing inspections all over, which are _technically_ valid, but
interfere with our convention of using verbatim string prefixes to
denote non-localisable strings. This, as a result, led to circular
inspections (addressing the r# inspection results in getting the
osu-localisation-analyser one, addresssing that one results in
getting the r# inspection back, etc. ad nauseam).
The fallback to "any of the added sets" needs to be applied after
they've all been added, rather than with every added one. Otherwise, in
flows that expect a particular difficulty to be selected in the end
(such as exiting from editor) would end up switching away from the
edited beatmap.
Sentry documentation suggests this should be on for a client-facing app.
We haven't run into issues without it until now, but might as well set it correctly?
