refactor: migrate monolithic crate to Cargo Workspace with Clean Architecture

Transform the single binary crate into a 9-crate workspace monorepo:

- Root Cargo.toml as [workspace] manager with resolver = "2"
- zesdex-entities: Domain entity types (session, settings, store, message, etc.)
- zesdex-utils: Pure utility functions (error, logger, pagination, slug, clipboard)
- zesdex-dto: Data Transfer Objects for LLM provider API communication
- zesdex-ipc: Unix-socket IPC layer (client/server/framing/protocol)
- zesdex-iam: Identity & Access Management (Clean Architecture: domain/application/infrastructure)
- zesdex-cms: Content Management (Clean Architecture: domain/application/infrastructure)
- zesdex-middleware: HTTP middleware (Auth, CORS, Rate Limiting)
- zesdex-libs: Composition root (AppContext, DB init, JWT, Argon2)
- zesdex-backend: Main binary entry point + seed/migrate binaries
- DevOps: Dockerfile, docker-compose, Nix (flake/shell/default), CI/CD updates
- Remove dead root src/ and src-misc/ directories

All crate re-exports maintain backward compatibility with original
crate::model::*, crate::dto::*, crate::ipc::* module paths.
Feature crates enforce strict layer separation: domain -> application
-> infrastructure with generic trait-based dependency injection.

crates/zesdex-backend/src/app/subagent/event.rs

@@ -0,0 +1,40 @@
+//! Event variants that a running subagent can emit to its parent via the
+//! shared mpsc channel.
+use serde_json::Value;
+
+/// Progress and outcome events emitted by `run_subagent` as it processes
+/// LLM responses and tool calls.
+#[derive(Debug, Clone)]
+pub enum SubagentEvent {
+    StepCompleted {
+        output: String,
+    },
+    StepFailed {
+        step: usize,
+        error: String,
+    },
+    Completed,
+    ToolCall {
+        tool: String,
+        args: Value,
+    },
+    ToolResult {
+        tool: String,
+        args: Value,
+    },
+    Progress(String),
+    /// Token usage reported by the LLM after one streaming call inside the
+    /// subagent. The drain thread accumulates these across all steps and
+    /// forwards the total to the parent's `TurnEvent::ReviewUsage` handler
+    /// so the Usage panel can split "main" tokens from "self-learning"
+    /// tokens (review, test-gen, arch-review, security-review, etc.).
+    ///
+    /// Why a separate variant instead of folding into `Completed`: usage
+    /// is reported per-step, so the parent can update the running total
+    /// incrementally rather than waiting for the whole subagent run to
+    /// finish. The drain thread still aggregates before forwarding.
+    Usage {
+        tokens_in: u64,
+        tokens_out: u64,
+    },
+}