[ZEPPELIN-6646] validate websocket payloads

[gyowoo1113]

What is this PR for?

WebSocket payloads are currently trusted after checking only the operation name. Message.receive() maps message.data to its declared TypeScript type without runtime validation, so malformed payloads can reach component handlers unchanged.

This PR adds an OP-based runtime payload guard convention at the SDK receive boundary. Guards are registered only for operations with a demonstrated payload failure, rather than auditing or validating every WebSocket message up front.

Message.receive() was chosen as the validation boundary because it already has both the OP and payload before the data is passed to subscribers, while keeping the existing interceptor contract unchanged.

LIST_UPDATE_NOTE_JOBS is the first guarded operation because ZEPPELIN-6551 demonstrated a concrete failure around partial job-removal payloads in the Job Manager. The guard preserves valid removal stubs and filters malformed non-removal updates before they reach subscribers. Additional OPs can be added to the registry when a concrete runtime failure demonstrates the need for validation.

It also catches errors thrown by @MessageListener handlers and logs them with the corresponding OP so the failure can be attributed to the WebSocket operation that triggered it.

ZEPPELIN-6645 was considered as part of the validation boundary. An empty interpreterSettings array is a legitimate server response when the user is not authorized for any interpreter setting. Since the payload shape itself is valid, the non-empty assumption belongs to the note-create handler rather than the WebSocket validation layer, so this PR does not add a shared payload guard for that case.

What type of PR is it?

Bug Fix

Todos

• - Add an OP-based runtime payload guard registry
• - Add validation for LIST_UPDATE_NOTE_JOBS
• - Apply registered payload guards in Message.receive()
• - Catch @MessageListener handler errors and log the corresponding OP
• - Add regression tests for payload validation and handler error handling

What is the Jira issue?

[ZEPPELIN-6646]

How should this be tested?

cd zeppelin-web-angular
npm run test:shell -- message.spec.ts
npm run test:shell -- message-listener.spec.ts

Both test suites pass successfully.

Screenshots (if appropriate)

N/A

Questions:

• Does the license files need to update? No
• Is there breaking changes for older versions? No
• Does this needs documentation? No