`onLoadRequested()` always released the `readyClickOperation` ongoing
operation, without checking whether it actually needs to/should (it
should only do so if the action initiating the operation was starting
the game by the host). This would crash all other consumers, who already
released the operation when their ready-up operation completed server
side.
To resolve, relax the constraint such that the operation can be ended
multiple times in any order. At the end of the day the thing that
matters is that the operation is done and the ready button is unblocked.
Finishing an operation started via
`OngoingOperationTracker.BeginOperation()` was risky in cases where the
operation ended at a callback on another thread (which, in the case of
multiplayer, is *most* cases). In particular, if any consumer registered
a callback that mutates transforms when the operation ends, it would
result in crashes after the framework-side safety checks.
Rework `OngoingOperationTracker` into an always-present component
residing in the drawable hierarchy, and ensure that the
`operationInProgress` bindable is always updated on the update thread.
This way consumers don't have to add local schedules in multiple places.
Fixes a potential crash when moving from main menu to editor after
having previously opened the login settings overlay. Setting the
activity in BDL as done before is unsafe, as that set can trigger value
change callbacks, which in turn can trigger adding transforms, which
should always be done on the update thread.
Semantically it also makes sense, as the user activity should change
once the screen they're moving to has actually loaded and displayed to
the user.
Culls another non-thread-safe mutation of the `Playing` bindable.
It seems to be a weird vestige from an earlier revision of the old
"direct" panel, which relied on `DisposeOnDeathRemoval` to finish track
playback (and then was removed in
6c150c9ed7). The play button is no longer
responsible for managing preview track lifetime anyway;
`PreviewTrackManager`'s method are intended for that.
Revealed by the framework-side transform thread safety checks. `Stopped`
is even annotated as not being thread-safe (but was annotated as such
long after the class's nascence).
