Websocket handlers NPE before an execution exists, and unparseable frames are never reported

### Describe the bug

Three defects in `amber/src/main/scala/org/apache/texera/web/resource/WorkflowWebsocketResource.scala`. All three were characterized during earlier coverage work (#7303, #7676) and deliberately left unpinned so a fix would not be blocked by a test asserting the broken behaviour.

**1 & 2. A workflow with no execution NPEs instead of reporting "not initialized".**

`WorkflowService.executionService` is a `BehaviorSubject` created with **no initial value**, so `getValue` is `null` until an execution is published.

- In the `case other =>` arm, `workflowStateOpt.map(_.executionService.getValue)` therefore yields `Some(null)`. That walks straight past the `case None` arm — the one that exists to report "workflow execution is not initialized" — and NPEs on `value.wsInput`.
- The `ModifyLogicRequest` arm has the same gap in a different shape: its guard tests `workflowStateOpt` where it means the execution, so `workflowStateOpt.get.executionService.getValue` returns null and NPEs one dereference later.

Line 89 of the same file already gets this right with `Option(...)`, as does `WorkflowService` itself at its lines 208 and 349 — so the correct idiom is established in-tree.

**3. An unparseable frame escapes the error mapper entirely.**

`objectMapper.readValue` sits **above** the `try`, so a frame the mapper cannot bind throws past the reporting path and the client is told nothing at all — no `WorkflowErrorEvent`, no entry in the execution's metadata store.

### How to reproduce?

Open a websocket for a workflow, send a runtime command or a `ModifyLogicRequest` before any execution has started: the handler NPEs rather than returning the friendly error. Separately, send a frame the mapper cannot deserialize: nothing is reported back.

### Version/Branch

main

### Task Type

- [ ] Refactor / Cleanup
- [ ] DevOps / Deployment / CI
- [ ] Testing / QA
- [ ] Documentation
- [ ] Performance
- [x] Other