[Remote rendering 5.1] pvserver connectivity spike

### 📝 Description of the feature

pvserver is a separate rendering process you connect to as a client, replacing the in-render window the spike used. This story is a timeboxed investigation to find out what integrating it actually takes, before committing to the implementation in 5.2. Backend-only. Open questions to answer:

- How does RemoteRenderer connect to a pvserver process, and does the existing trame-rca streaming path still work unchanged once it does?
- What happens to the session lifecycle now that rendering is in another process?
- Do the per-part mutation triggers and VtkNodePipeline still work when the VTK objects live in pvserver's process rather than ours, or do they need to be marshaled across the boundary?
- Does interaction (the interactor path, including the 4.5 workaround) change with pvserver in the loop?
- Does any state, camera, per-part, need to be serialized/synced across the boundary that was previously just set directly?
- How is pvserver packaged into the deployment environment?

### Acceptance Criteria

A findings doc answering the above, enough to scope 5.2, including any gaps we didn't account for in Phase 4

### 💵 Business Value

_No response_

### 🔗 Useful links and references

_No response_