refactor(assistant): finalize unified governance storage

[kaizhou-lab]

Background

This backend PR is not just adding a few new assistant fields. It restructures assistant data into a unified governance model that can support the phase-1 frontend, conversation creation, runtime restoration, and downgrade compatibility.

Before this change, assistant-related data was split across:

• assistants
• assistant_overrides
• builtin assets (assistants.json / rules / avatars)
• conversation extra

That fragmentation caused several problems:

• builtin and custom assistants behaved differently
• remembered values and fixed defaults were mixed together
• conversation restoration still depended on extra
• the phase-1 governance UI and Guid could not rely on one assistant model

What This PR Changes

1. Introduces unified assistant governance storage

This PR formalizes three core storage layers:

• assistant_definitions
  • canonical assistant definition
  • stores stable identity, profile, rules, recommended prompts, and default model / permission / skills / MCP
• assistant_overlays
  • user-side overlay state
  • stores enabled state, sort order, last used time, and main-agent override
• assistant_preferences
  • remembered values for auto mode

Key points:

• builtin and user assistants are both materialized into assistant_definitions
• extension assistants are no longer part of the unified assistant catalog
• the legacy builtin skills/ directory is removed from governance semantics
• avatars are normalized into avatar_type + avatar_value

2. Moves assistant snapshots out of conversation extra

This PR adds:

• conversation_assistant_snapshots

This table is used to:

• freeze assistant-bound conversation values at creation time
• restore assistant conversations from a conversation-level source of truth
• persist runtime changes for assistant-bound conversations without depending on extra

This also clarifies runtime ownership:

• assistant conversation: conversation_assistant_snapshots
• plain ACP conversation: acp_session
• plain aionrs conversation: existing conversations.model-based runtime path

3. Clarifies default semantics as auto | fixed

Default mode handling is reduced to two supported semantics:

• auto
• fixed

The service behavior is now:

• auto -> fixed
  • the request must carry the fixed value
  • the service also seeds that value into assistant_preferences
• fixed -> auto
  • the service clears the remembered value for that item from assistant_preferences
• fixed values are no longer treated as remembered values
• only auto participates in preference replay semantics

4. Aligns assistant conversation creation and runtime updates

• assistant conversation creation now uses an explicit top-level assistant request object
• only assistant governance fields introduced on this branch were moved out of extra
• existing main conversation extra fields remain untouched
• creating an assistant conversation now:
  • writes conversation_assistant_snapshots
  • writes assistant_preferences only for auto
• runtime updates inside assistant conversations now:
  • update snapshots
  • additionally update preferences for auto
• plain agent conversations keep their original runtime behavior and are not polluted by assistant governance defaults

5. Preserves downgrade compatibility

• builtin assets remain the authoring source, but runtime reads come from unified storage
• assistants / assistant_overrides are retained as downgrade mirrors
• builtin assistants are no longer mirrored back into legacy assistants, preventing duplication on old versions
• branch-only repair logic used during local development was removed from the final code path; the final branch keeps the normal migration path only

Design Impact

This PR resolves four core design issues:

1. assistant definition, per-user overlay, and remembered values are stored as separate concepts
2. assistant conversations and plain agent conversations use different runtime truth sources
3. assistant snapshots are no longer mixed into conversation.extra
4. the phase-1 governance UI and Guid can consume one consistent assistant model

Verification

• just push
• cargo nextest run --workspace
• assistant / conversation / migration / app e2e coverage is included in branch verification