llm request tracking, user context cleanup, minor fixes

crates/core-api/src/chatbot.rs

@@ -39,6 +39,13 @@ pub struct ChatOptions {
     /// providers — only the logging wrapper reads them.
     pub session_id:  Option<i64>,
     pub stack_id:    Option<i64>,
+    /// The authenticated user driving this request. Correlates the metadata row
+    /// in `system.db` with the payload in `{userid}.db`. Logging-only.
+    pub user_id:     Option<String>,
+    /// UUID correlating the metadata row (`llm_requests`) with the payload row
+    /// (`llm_request_payloads`). Generated by the LLM loop before the call.
+    /// Logging-only.
+    pub request_id:  Option<String>,
 }
 
 /// Raw HTTP metadata captured during a provider call.

crates/core-api/src/plugin.rs

@@ -30,13 +30,9 @@ pub type RouterFactory = Arc<dyn Fn() -> axum::Router + Send + Sync>;
 /// `RemotePlugin`.
 #[derive(Clone)]
 pub struct PluginContext {
-    pub chat_hub:                Arc<dyn ChatHubApi>,
     /// Custom file-based slash commands (`commands/<name>/`). Read-only from the
     /// plugin side — lets the Telegram bot resolve `/command` expansions.
     pub command:                 Arc<dyn CommandApi>,
-    pub approval:                Arc<dyn ApprovalApi>,
-    /// Unified Inbox façade (approvals + clarifications). See plugin.md §12.2.
-    pub inbox:                   Arc<dyn InboxApi>,
     /// Skald's shared SQLite pool — lets plugins create/use their own tables
     /// (e.g. `relay_*`) in the main DB. See plugin.md §12.1.
     pub db:                      Arc<sqlx::SqlitePool>,