fix(conversation): always send type and extra in create body (aioncore v0.1.72 compat)

[shoppingarena]

Problem

On aioncore v0.1.72, every first submit from the home screen fails with 400 Invalid JSON request body when a conversation is created with an assistant selected.

Root cause

The backend now requires the top-level type and extra fields in POST /api/conversations. However:

• buildCreateConversationBody() sets type: undefined whenever an assistant is present (JSON.stringify then drops the key), and drops extra when it is not set
• the useGuidSend call sites never pass type

Resulting body {"assistant":{...}} (no type, no extra) → 400.

Verified against a live v0.1.72 backend:

• {"assistant":{"id":X}} → 400
• {"assistant":{"id":X},"type":"aionrs","extra":{}} → 201

Fix

• always pass type through in the body builder and default extra to {}
• set the engine type ('aionrs' | 'acp') at both useGuidSend call sites

Verified end-to-end after rebuild: first submit with an assistant creates the conversation successfully.

[shoppingarena]

Updated the 4 unit-test assertions that encoded the old contract (type stripped when an assistant is present) — they now expect the engine type to be passed through, per the aioncore v0.1.72 requirement. Both affected test files pass locally (40/40).

For the maintainers: on the v2.1.61 + aioncore v0.1.72 combo this is reproducible live — first submit from the home screen with any assistant selected returns 400 Invalid JSON request body, because the emitted body {"assistant":{...}} has no type/extra. Happy to adjust if you prefer fixing this on the backend side instead (making those fields optional again).

[codecov]

Codecov Report

❌ Patch coverage is 0% with 1 line in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
...kages/desktop/src/common/adapter/apiModelMapper.ts	0.00%	0 Missing and 1 partial ⚠️

📢 Thoughts on this report? Let us know!