The reason this was happening was an unfortunate oversight in the
migration logic. The code that was attempting to parse the skin settings
as `int` was firing regardless of whether a skin migration from EF to
realm had already occurred. If it had occurred, the skin setting would
contain a GUID rather than an integer, and therefore fail to parse, and
therefore implicitly fallback to a EF skin ID of 0 which would be the
default skin.
Fix by not running the setting migrating logic at all when there are no
EF skins to migrate.
* `RealmRulesetSetting` was added in 2021.916.0.
* `RealmKeyBinding` was added in 2021.703.0.
Attempting to upgrade from older releases than the above would cause
migrations up to schema versions 10 and 11 to fail.
For compatibility reasons, we quite often convert completely unmanaged
instances to `ILive`s so they fit the required parameters of a property
or method call. This ensures such cases will not cause any issues when
trying to interact with the underlying data.
Originally I had this allowing write operations, but that seems a bit
unsafe (when performing a write one would assume that the underlying
data is being persisted, whereas in this case it is not). We can change
this if the requirements change in the future, but I think throwing is
the safest bet for now.