feat(assistant): support image avatar for generated (custom agent) assistants

## Background

Companion issue to iOfficeAI/AionUi#3599 (custom agents cannot use image avatars).

User-source assistants already support image avatars end to end: `normalize_user_avatar_input` (aionui-assistant/src/service.rs) copies a local image path into the managed `assistant-avatars/` dir and the avatar is served via `/api/assistants/{id}/avatar`.

However, the custom-agent → assistant sync path hardcodes the agent's `icon` as emoji:

- `service.rs` (sync of generated definitions): `avatar_type = if avatar_value.is_some() { "emoji" } else { "none" }` — the `icon` value is never routed through the avatar persistence flow, so a local image path stored in `icon` would be treated as an emoji string and later filtered out by `assistant_avatar_response_value` (local paths are projected to `None`).

## Proposal

In the generated-assistant sync, when `row.icon` looks like a local image path, run it through the existing `normalize_user_avatar_input`-style persistence (copy to managed dir, set `avatar_type = "user_asset"`) instead of always tagging it as emoji.

Regression watch: existing custom agents with emoji icons must keep working unchanged.

## Scope decision

Deferred for now — filed for tracking together with the AionUi-side UI work.

Start in aionui-assistant/src/service.rs, reading normalize_user_avatar_input, the generated-definition sync, and assistant_avatar_response_value. Trace how user-source image paths are copied into assistant-avatars/ and served through /api/assistants/{id}/avatar. Done means local image paths from row.icon persist as user_asset avatars while existing emoji icons remain unchanged; the related AionUi UI work is explicitly deferred.

Written by the indexing model from the issue text.