side-question (/btw) endpoint is a stub returning hardcoded placeholder; implement real handler

[IceyLiu]

Summary

The /btw "side question" (by-the-way) feature in AionUi does not work: when a user runs /btw <question> inside a Claude Code (acp/claude) conversation, the SIDE QUESTION overlay shows a hardcoded placeholder answer instead of a real answer:

Side question support will be fully wired in app integration phase.

Root cause (confirmed from the AionUi side)

The AionUi front-end is fully wired — the /btw command parsing, the overlay UI, the IPC bridge, the endpoint call, and the response handling all work correctly. The placeholder string does not exist anywhere in the AionUi TypeScript/JS source, i18n, mocks, or fixtures — it is only present inside the compiled aioncore backend binary.

The endpoint is:

POST /api/conversations/{conversation_id}/side-question
body: { "question": "..." }

Response shape expected by the client:

{ status: 'ok'; answer: string }
| { status: 'noAnswer' }
| { status: 'unsupported' }
| { status: 'invalid'; reason: 'emptyQuestion' }
| { status: 'toolsRequired' }

Currently the backend handler for this endpoint appears to be a stub that returns { status: 'ok', answer: "Side question support will be fully wired in app integration phase." } — i.e. it always answers with the placeholder text, so the feature looks broken/"integration failed" to users.

Expected

Implement the real side-question handler in aioncore so /btw actually asks the side question against the running Claude Code conversation and returns a genuine answer (or the appropriate noAnswer / unsupported / toolsRequired status), instead of the hardcoded placeholder.

Notes

• Not fixable from the AionUi (packages/desktop) repo — the TS layer already forwards the request and renders whatever answer the backend returns. The fix must land in this backend crate and ship in a rebuilt aioncore binary.
• Front-end eligibility gate: /btw is only offered when type === 'acp' && backend === 'claude'.