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).
This API endpoint is intended for usage with the entire `solo_scores`
machinery and ID schema, rather than the legacy `*_scores_high` ID
schema. It also supports automagically falling back to downloading
legacy replays if a stable-imported score is requested for download
(internally this happens via `legacy_score_id` in the `data` json).
This change will allow replays to be downloaded, but it will still not
yield 100% correct behaviour, as there is further work to be done in
that respect. The download tracker is expecting score hashes to arrive
from web to verify the integrity of the incoming download, but the API
does not expose such a facility right now; we will have to decide as to
whether we want to add one web-side, or whether we want to disable the
checking client-side.
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.
