feat(plugins): plugin pages, per-user config, capabilities gate, mobile/telegram refactors

- Plugin HTTP routes + web pages (plugin-page-host, plugin-catalog, plugin-detail)
- Plugin access grants + per-user config (DB tables + API + frontend forms)
- Capabilities-based guard (caps.rs) replacing role-id checks
- Mobile connector: message routing, payload types, router refactor
- Telegram bot: auth flow, event handling improvements
- Honcho plugin: substantial rework
- Sidebar: plugin pages integration, role-driven visibility
- i18n: new strings for plugins, connectors, capabilities
- Remove unused mascot asset

crates/core-api/src/user_plugin_config.rs

@@ -0,0 +1,16 @@
+use anyhow::Result;
+use async_trait::async_trait;
+use serde_json::Value;
+
+/// Per-user plugin configuration store (`plugin_user_configs` table in
+/// `system.db`).
+///
+/// Values are deliberately admin-readable — the table lives in the registry
+/// database — so `user_config_schema`s must never collect secrets. A plugin
+/// that needs per-user secrets should keep them elsewhere.
+#[async_trait]
+pub trait PluginUserConfigApi: Send + Sync {
+    async fn get(&self, plugin_id: &str, user_id: &str) -> Result<Option<Value>>;
+    async fn set(&self, plugin_id: &str, user_id: &str, config: Value) -> Result<()>;
+    async fn delete(&self, plugin_id: &str, user_id: &str) -> Result<()>;
+}