feat: [Remote rendering 3.2b] save state reads from server camera

[LKasianAnsys]

Issue

Addresses #20

Context

This is the second of 4 PRs for user story 3.2 (#20) of the phased implementation plan (ADR here) for adding remote rendering in VISOR.

PR 3.2a added a server-side camera record and populated it on load_state. The save path still takes its camera from the browser's reply to the save-time round trip, so the server holds a camera it does not yet use.

This PR is the second step: get_state now takes scene.camera from the record instead of from the client's reply, so the browser is no longer a camera source on the save path. The round trip itself is unchanged; only the camera field is superseded. Gestures do not reach the record until PR 3.2d, so the record still reflects the loaded camera at this point (see below).

Note before testing: In this PR, save_state writes the camera that was loaded, not the camera the user has moved to. That is the expected intermediate state. To test:

• Load a saved state that has an off-axis camera
• Move the camera in the viewer to a visibly different framing
• Save to a fresh directory
• Confirm scene.camera in visor.json matches the loaded camera. (PR 3.2d is where the actual browser camera will be reflected in the persisted state)

Two cleanups are included as described in the auto-generated summary below; the duplicate camera declaration in PersistedSceneState is removed, and setCameraStateAsync now takes only the seven fields it applies. Neither changes the runtime behaviour.

---

Copilot summary

This pull request ensures that when saving the viewer state, the camera information is always sourced from the server's authoritative camera record, rather than from the browser's reply or the VTK pipeline. It also introduces a clear distinction between the camera state that can be applied from the frontend and the full camera state, and adds comprehensive tests to guarantee correct behavior.

Key changes include:

Backend logic and data model:

• In get_state, the camera is now always taken from the renderer's record (get_camera_state()), never from the browser's reply or the pipeline. [1] [2]
• The PersistedSceneState model cleans up a duplicate camera field.

Frontend/TypeScript API:

• Introduced the AppliedCameraState type, representing only the seven camera fields that can be set from the frontend, and updated the IRenderer interface and implementations to use this type for setCameraStateAsync. [1] [2] [3] [4] [5] [6]

Testing and verification:

• Added and expanded integration and unit tests to verify that saving state writes the server's camera record, not the browser's, and that the correct camera is chosen in all scenarios—including when the record is absent. [1] [2] [3] [4]

[ansBAkula]

Tested.

The base branch was changed.