[ZEPPELIN-6742] Connect the AI Assistant frontend to conversation REST and WebSocket APIs

[voidmatcha]

What is this PR for?

Connect the Assistant frontend to the conversation REST and WebSocket APIs. The transport provides conversation creation and retrieval, message sending, and response delivery for the UI.

Server PR #5547 has merged. This PR still depends on shared prerequisites #5558 and UI contracts #5561; its temporary base contains those changes for review.

What type of PR is it?

Feature

Todos

• Merge [ZEPPELIN-6733] Add AI assistant chat to notebooks (server-side) #5547
• Merge [ZEPPELIN-6738] Upgrade React to 19 and fix shared host integration #5558 and [ZEPPELIN-6741] Define shared AI Assistant UI contracts and message history behavior #5561 before this PR
• Rebase onto master, retarget this PR to master, and rerun CI before merging
• Compare against the final API contract from server PR [ZEPPELIN-6733] Add AI assistant chat to notebooks (server-side) #5547
• Confirm CI on the current PR head

What is the Jira issue?

ZEPPELIN-6742

How should this be tested?

Run from zeppelin-web-angular/:

npm run build-project:sdk
npm run typecheck:react
npm --prefix projects/zeppelin-react test -- src/entities/assistant/model/assistantTransport.spec.ts

Also verify the REST and WebSocket integration against the final API contract from server PR #5547.

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

[voidmatcha]

This PR connects the frontend to the conversation REST API and WebSocket run events.

The current diff is +1,527/-1 across four files. Excluding 869 lines in *.spec.* tests, the review diff is +658/-1. There is no lockfile change.

Server PR #5547 has merged. This PR still depends on #5558 and #5561, which are included in its temporary base for review. After those prerequisites merge, I will rebase and retarget the PR to master, then verify the final API contract and CI before merging. CI passes on the current PR head; I will rerun it after the final rebase.

[miinhho]

Transport-level review. I reproduced the reported sequences by loading the module and controlling HTTP responses and socket events. I have not verified them against a live server or the notebook UI. The authentication comment is a contract question, not a confirmed integration defect.

[miinhho]

This removes the previous disconnected marker before the new request has been accepted.

I reproduced this sequence: run A starts, its connection closes, and a retry is sent without reloading history. When that retry receives run.failed with status 409, the transport reports idle, even though A's history has not been recovered. The failure message itself says the conversation is still answering.

This conflicts with the documented behavior of retaining the lost-connection state until history is reloaded. Please preserve that uncertainty when the retry is rejected, and cover the disconnect → retry → 409 sequence in a regression test.

[voidmatcha]

Thanks for catching this. The disconnected state now remains until the retry is accepted by the server. I also added a regression test for disconnect -> retry -> 409.

Fixed in 7ad64ff.

[miinhho]

A successful latest-page response clears the current disconnected marker without checking whether the request predates that disconnect.

I reproduced this with an accepted run: start getMessages(), delay its response, close the socket, then release the history response. The state changes from disconnected to idle, although no history request was started after the connection loss.

Please ensure that a request spanning a newer disconnect cannot clear that disconnect's recovery state, and add a regression test for this ordering.

[voidmatcha]

Thanks for catching the race. A history response requested before a disconnect can no longer clear that disconnect state. I added a regression test for this response ordering as well.

Fixed in 6de3a98.