These can be tested by adding a `Task.Delay(3000);` at the end of the
`MultiplayerClient.JoinRoom` task. The reason is typically that
`Client.Room` becomes not-null but the join task still hasn't completed
yet, so e.g. the ready button is still disabled.
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.
