chore: [Remote rendering 3.6a] Cleanups after moving authority to server

[LKasianAnsys]

Issue

Addresses #24

Context

Feature #19 is Phase 3 of the remote rendering epic (#15), which moves the viewer state authority from the client to the server. The first 5 user stories in this phase moved ownership of all of the pieces of the viewer state to the server. User story 3.6 is to clean up unused scaffolding and to review the save/load state workflow to ensure it works end to end as expected with the new state authority model.

This PR includes two main cleanups:

1. Remove the server-to-client round trip that previously asked the client for the viewer state during the save_state API. This includes frontend and backend code that can now be retired, now that the server reads its own records during save_state.
2. Remove the client-side reapplication of its own cached state during onServerUpdateAsync. Previously, when the server received an API call and triggered an update on the client, the server would push stale viewer state, requiring the client to cache its previous state and reapply it after the server push. This is no longer needed now that the server is the authority on the viewer state.

Manual checks:

• on add_dataset, viewer state looks correct for the pre-existing dataset. Start viewer with a dataset, color a part by a variable, turn on some widgets, change the camera orientation. Run add_dataset to add a new dataset; check that the first dataset's state, and the state of widgets and camera (and UI panels and tabs) looks as it did.
• check that save_state works as expected. After the first check above, run the save_state API. Initialize a new VISOR instance, and start it with no dataset. Run load_state to load the previously saved state. Check that it produces the same viewer state as the original VISOR instance.

Copilot summary

This pull request removes the frontend round-trip for saving viewer state, making the server the sole authority for building and persisting the viewer state. The changes simplify the codebase by eliminating now-unnecessary async calls, models, and handlers related to client-side state retrieval. Saving now works even if no client is connected, improving robustness and maintainability.

Major changes include:

Removal of frontend authority and async state retrieval

• The server now builds the persisted viewer state directly from its own records, removing the need to request state from the frontend. The save_state method in VisorVTK and the get_state method in VisorSceneBase have been refactored to be synchronous and no longer await frontend responses. (F6231c12R364, F738364eR236, F738364eR272)
• The abstract method _get_runtime_state_async and related frontend round-trip logic have been removed from VisorSceneBase and its subclasses. (F738364eR186, F4dfffcdR41)
• The save_state_response trigger and handler have been removed from LocalApp and related classes, since the server no longer expects a response from the frontend. (F0d5e153R206, F0d5e153R234, F0d5e153R242, F0d5e153R306, F6887ffeR42, F738364eR405, F4dfffcdR64)

Model and code cleanup

• The VisorSaveStateRequest and VisorSaveStateResponse models, which were used for client-server state exchange, have been deleted as they are no longer needed. [1] [2]
• Imports and type checking related to the removed models have been cleaned up. (F738364eR5, F738364eR24, F738364eR35)

[ansBAkula]

@LKasianAnsys ,
Thanks for the PR. I tested the suggested checks, and I’m seeing some unexpected behavior when loading a saved state into an empty viewer instance. I may be missing something, so I wanted to check with you.
These are the steps I followed:

1. Load a dataset and interact with the viewer.
2. Save the state.
3. Start a new viewer instance.
4. Load the saved state.

The resulting scene looks a bit unusual and the viewer seems to be frozen. I've attached screenshots for reference.
Expected:

What we get:

[LKasianAnsys]

Hi @ansBAkula Thanks so much for testing and sharing your results. Yes let's discuss more tomorrow, as I haven't been able to reproduce on my end so far.

At a glance, this looks quite similar to what I've been seeing in separate issue (issue #122, I believe it's an upstream issue, filed with Kitware, but there's a workaround/partial fix pending in #169). If you're using WSL on your Windows machine I believe it also reproduces there, could that be the case?

[LKasianAnsys]

@ansBAkula The workaround fix in #169 has been merged, and this PR has been rebased on main, so you should now be unblocked from testing the load_state workflow on this and the other PRs.