Fix session isolation for shared agents

[MkDev11]

What problem does this PR solve?

When multiple users share the same agent simultaneously, there was no isolation mechanism. Historical memories and conversation state were being overwritten by subsequent requests because the canvas state was stored in the shared agent DSL.

The SDK's /agents/<agent_id>/completions endpoint already had session isolation, but the web UI's /completion endpoint in canvas_app.py did not.

Fixes #11697

Type of change

• Bug Fix (non-breaking change which fixes an issue)

[MkDev11]

@KevinHuSh please review the changes and let me know your feedback. thanks.

[KevinHuSh]

Appreciations!
This API is called by front-end. There's corresponding front end alterations too, isn't it?
Plus, once the message is stored, it might be never retrieved again if this canvas is not used by team simultaneously.
That might waste DB a lot.

[MkDev11]

@KevinHuSh Thanks for the review!

The frontend already supports session_id - I checked use-send-agent-message.ts and it already stores the session_id from responses and passes it back in subsequent requests. The wiring was there, just not being used because the backend wasn't returning session_id. So no frontend changes needed.

For DB waste: sessions are only created when users actually chat with the agent. We could add a cleanup job for old sessions in a follow-up PR if needed.

[MkDev11]

@ZhenhangTung can you review the PR and let me know your feedback? seems like Kevin is busy

[ZhenhangTung]

@MkDev11 I’m a product manager, so I’m not able to review code directly :( Kevin will review it when he is available.

[MkDev11]

@KevinHuSh Really sorry to bother you. Could you please review the PR again and help me merge it so that I can continue working on other issues?

[KevinHuSh]

No session_id. So, once stored in table 'API4Conversation' and never used. It makes no sense.

[MkDev11]

@KevinHuSh Regarding session_id: null in the screenshot - that's the first request, which is expected. The frontend already handles session persistence:

1. First request: session_id: null → backend creates session → returns session_id in response
2. Frontend captures it via setSessionId(answerList[0]?.session_id) (line 448 in use-send-agent-message.ts)
3. Subsequent requests include the stored session_id

The session gets reused on follow-up messages in the same conversation.

[MkDev11]

@Magicbook1108 Can you please review this PR as well?

[MkDev11]

@KevinHuSh Is it impossible to approve this PR yet?