fix: persist API @agent chats into thread history

[LHMQ878]

Summary

• chatSync saved @agent replies with include: false and without threadId / user, so they never appeared in API thread history. Streaming already persisted correctly.
• Align the sync agent path with streamChat: include: true, pass threadId and user.
• Adds a mocked regression test for the WorkspaceChats.new payload.

Fixes #5060

Test plan

• POST /api/v1/workspace/:slug/thread/:threadSlug/chat with @agent ... then GET thread chats — the turn is present
• Confirm streaming @agent chats still persist as before

Made with Cursor

[timothycarambat]

Scope & behavior of this change

This only impacts developer API (/v1/...) chats, and only @agent turns. The change is entirely inside apiChatHandler.js, which is only called by the v1 REST endpoints. Regular UI chats, websocket agent chats (which persist via the chatHistory aibitat plugin), the embed widget, and the OpenAI-compat endpoint are all untouched. Even within the API, non-agent chats already saved correctly — only @agent turns were broken.

What it changes: where saved agent rows become loadable. The frontend and API have no special agent logic — they just query chats by the (user_id, thread_id, api_session_id) triple + include: true. This fix makes the agent save carry the same triple as the invocation (identical to the non-agent saves in the same file), so each real-world combination now lands where its readers expect:

Combination	Endpoint	Now visible in
No user, no thread, no session	POST /v1/workspace/:slug/chat	Workspace default chat (UI + GET /chats), context for next API chat
No user, no thread, sessionId	POST /v1/workspace/:slug/chat + sessionId	That session's history only (never visible in UI — api_session_id rows are always excluded from frontend queries)
Thread, no user (single-user)	POST /v1/workspace/:slug/thread/:threadSlug/chat	Thread history in UI + GET /thread/:slug/chats, context for next thread chat
Thread + userId (multi-user)	POST /v1/workspace/:slug/thread/:threadSlug/chat + userId	Same, attributed to that user — their UI thread view and their context lookups find it

Before this fix, all four combinations saved agent turns in a shape (include: false, no thread_id, no user_id) that no reader queries — stored but unreachable, which is why the issue read as "agent chats vanish" (#5060).

Note: user/thread and sessionId are mutually exclusive across the endpoints — a user-attributed row can never carry an api_session_id, which keeps session-scoped history queries (user_id: null filter) safe. The test suite enforces this invariant.

One user-visible nuance (single-user mode only): sessionless workspace-level API agent chats go from invisible to appearing in the desktop UI's main workspace chat — same as normal API chats have always done, so this is alignment, but it is a visible change. In multi-user mode this cannot occur: the UI loads workspace history per-user (forWorkspaceByUser filters user_id), and the workspace-level API endpoint always saves with user_id: null, so these rows never match any user's view.

[LHMQ878]

Thanks @timothycarambat — that table matches the intent. The only user-visible change is the single-user, sessionless workspace-level API @agent turn showing up in the main UI chat, same as non-agent API chats already did.