fix(conversation): rebuild agent runtime after workspace changes

[zilongshao]

Summary

Fix stale agent runtime reuse after a conversation workspace is changed or moved.

Previously, updating conversation.extra.workspace could leave the in-memory agent bound to the old workspace. Runtime workspace persistence could also overwrite a newly selected non-empty workspace with a stale resolved path.

Changes

• Detect normalized workspace changes during conversation updates and recycle the cached agent with an explicit WorkspaceChanged reason.
• Defensively compare the cached agent workspace with the requested workspace in the task manager.
• Use identity-checked slot removal and single-flight initialization so concurrent rebuild requests create only one replacement agent.
• Invalidate and refresh runtime tokens when rebuilding the task.
• Restrict automatic workspace persistence to empty legacy values and re-read the latest database row before writing.
• Add unit, integration, concurrency, token-rotation, and directory-move E2E coverage.

Verification

• cargo fmt --all -- --check
• cargo clippy -p aionui-common -p aionui-ai-agent -p aionui-conversation -p aionui-app -- -D warnings
• cargo test -p aionui-ai-agent task_manager::tests --lib
• New conversation workspace tests (7)
• cargo test -p aionui-app --test message_e2e workspace_move_patch_keeps_two_message_turns_on_new_workspace -- --exact
• just push (9,262/9,262 selected tests passed locally; verified upstream Windows-incompatible tests were excluded only by an untracked local nextest profile, while CI retains the repository configuration)

Observability

Existing structured lifecycle logging was extended with conversation ID, change flags, and rebuild reason. Workspace paths are intentionally not logged.