[Bug]: Testing module can get in a non-escapable state if runs are not completed

[JReinhold]

The testing module UI updates its own state (running/cancelling/done, etc.) when it receives updates from the server. It also saves the state in the browser's session storage.

That can cause issues, if the manager UI doesn't receive updates from the server, because:

• The server is closed before tests are completed
• Tests are completed when the browser is closed
• The server code bugs out and never sends new state update

All of these pretty common cases can lead to the testing module getting in a non-escapable locked state, where it is forever running, and you can't re-run or cancel the "current" run, because the server is in a completely different state.

This is explained in the following video:

Export-1731622446365.mp4

I think, that ideally the server state should be the single source of truth, and the manager shouldn't try to keep its own state, nor should it save it to session storage, because the server is the only entity that knows what the status of a run is. When the manager UI starts up (ie. the SB app is loaded), it should ask the server for what the current state is.

It should also be able to handle loosing connection to the server, resetting the run state in the UI.

We could maybe leverage the useUniversalState POC that I have built here: next...jeppe/universal-state

Also open to other suggestions.

Discussed internally at https://chromaticqa.slack.com/archives/C07AXQABXDZ/p1731622600573489