Another month, another freak android build failure.
From what I can tell, this time the build is broken because the second-
-to-last workaround applied to fix it, namely explicitly specifying
the version of workloads to install, stopped working, presumably because
github pushed a new .NET SDK version to runners, and microsoft didn't
actually put up a set of workload packages whose version matches the
.NET SDK version 1:1.
Thankfully, the fix to the *last* android build breakage (which caused
the workload installation to completely and irrecoverably fail), appears
to be rolling out this week, and *also* fix that same second-last issue,
so both workarounds of specifying the workload version and pinning the
image to `windows-2019` appear to no longer be required.
Note that the newest image version, 20250209.1.0, is still not fully
rolled out yet, thus rather than just fix all builds, this will fix like
20% of builds until the newest image is fully rolled out. But I guess
a 20% passing build is better than a 0% passing build, in a sense...?
I believe once upon a time the `SelectedRoom` bindable used to be bound
to `RoomManager.JoinedRoom` or similar. But now it's effectively private
to the lounge subscreen and so a lease is unnecessary.
Mostly trying to give more space to the queue as we add more vertical
elements to the middle area of multiplayer / playerlists. This whole UI
will likely change – this is just a stop-gap fix.
In particular I don't like the non-null assert around
`GetCurrentItem()`, because there's no reason why it _couldn't_ be
`null`.
Consider, for example, if these panels are used in matchmaking where
there are no items initially present in the playlist.
The ruleset nullability part is debatable, but I've chosen to restore
the original code here.