Refactor amber engine to stop depending on amber/web internals

### Task Summary

Four files under `amber/src/main/scala/org/apache/texera/amber/` (the engine) import classes from `org.apache.texera.web.*`, violating the engine-vs-web layering:

- `amber/clustering/ClusterListener.scala` — imports `web.SessionState`, `web.model.websocket.response.ClusterStatusUpdateEvent`, `web.service.{WorkflowExecutionService, WorkflowService}`, `web.storage.ExecutionStateStore.updateWorkflowState`
- `amber/engine/architecture/controller/Controller.scala` — imports `web.SessionState`, `web.model.websocket.response.RegionUpdateEvent`
- `amber/engine/architecture/scheduling/RegionExecutionCoordinator.scala` — imports `web.SessionState`, `web.model.websocket.event.RegionStateEvent`, `web.resource.dashboard.user.workflow.WorkflowExecutionsResource`
- `amber/engine/architecture/pythonworker/PythonWorkflowWorker.scala` — imports `web.resource.pythonvirtualenvironment.PveManager`

The engine actors push WebSocket events directly through web's `SessionState` plumbing and reach into web-side resources. Correct shape is the engine exposing an event stream / interface that web subscribes to, and web-resident utilities like `PveManager` moving to the engine side if the engine genuinely owns the lifecycle.

This is a prerequisite for #5423: once these leaks are gone, upgrading the web layer's Dropwizard version no longer forces the engine to recompile against new web types.

Part of #5423.

### Task Type

- [x] Refactor / Cleanup