fix(image-generate): save generated images into the caller's workspace

image_generate wrote the file into the server's own data/images/ and handed
that host path to the model. It is a path in nobody's vocabulary: not the
caller's home, not their container. Telegram's send_attachment therefore
resolved it under the user's home and answered "file not found", and
read_file, execute_cmd and the viewer could not reach it either. The web URL
was the only surface that worked, which is why the failure only ever showed
on Telegram -- and why the model there, having no working way to hand the
file over, started inventing send_photo and send_media.

Placement moves to the tool, the one place holding a ToolContext:

- The manager returns bytes (generate_bytes) and no longer knows where an
  image goes. It has no UserFs and no session, so it never could have.

- run_with saves through uploads::save_to_home into uploads/{session}/. The
  returned path is agent vocabulary, so every consumer resolves it, and that
  is the one directory the media inliner is authorized to read from -- a
  vision model can be shown the image it just made. execute_async, the
  context-free path, now fails loudly rather than writing somewhere nobody
  can read; same shape as execute_cmd.

- The extension is sniffed rather than assumed png: it is what decides
  whether Telegram sends the picture inline or as an anonymous document, and
  providers return jpeg and webp too. The file is named after the prompt, so
  it reads as something in the explorer and in Telegram.

The result still carries a url, since the chat renders Markdown images and
![](url) beats naming a file the user then has to open. It points at
/api/file?path=..., which resolves through the caller's own UserFs. The old
/api/images/{id} route is removed: it had no writer left once placement
moved, and it addressed one instance-wide directory behind require_auth
alone, with no notion of who owned the image -- the same shape as the /data
static mount removed before it. That leaves data_root unused, so the manager
no longer knows about the server's filesystem at all.

Docs: the Telegram page explains send_attachment as the channel's equivalent
of show_file_to_user; the ComfyUI page says where a generated image lands and
which of the two handles to use where.

Also introduces CHANGELOG.md and the standing rule for it in CLAUDE.md.

crates/skald-core/src/image_generate/manager.rs

@@ -9,12 +9,10 @@
 ///
 /// `get(id)` resolves by explicit id across both plugin and DB-backed providers.
 /// When called without an id, plugin providers take precedence over DB-backed ones.
-use std::path::PathBuf;
 use std::sync::Arc;
 
-use anyhow::{Context, Result, anyhow};
+use anyhow::{Result, anyhow};
 use async_trait::async_trait;
-use rand::RngExt;
 use sqlx::SqlitePool;
 use tokio::sync::RwLock;
 use tracing::{info, warn};
@@ -50,14 +48,12 @@ pub struct ImageGeneratorManager {
     pool:      Arc<SqlitePool>,
     registry:  Arc<ProviderRegistry>,
     state:     RwLock<ManagerState>,
-    data_root: PathBuf,
 }
 
 impl ImageGeneratorManager {
     pub async fn new(
-        pool:      Arc<SqlitePool>,
-        registry:  Arc<ProviderRegistry>,
-        data_root: impl Into<PathBuf>,
+        pool:     Arc<SqlitePool>,
+        registry: Arc<ProviderRegistry>,
     ) -> Result<Arc<Self>> {
         let mgr = Arc::new(Self {
             pool,
@@ -66,7 +62,6 @@ impl ImageGeneratorManager {
                 db_slots: Vec::new(),
                 plugins:  Vec::new(),
             }),
-            data_root: data_root.into(),
         });
         mgr.reload().await?;
         Ok(mgr)
@@ -192,32 +187,30 @@ impl ImageGeneratorManager {
 
     // ── Generation ────────────────────────────────────────────────────────────
 
-    pub async fn generate(
+    /// Renders `prompt` with `provider_id` and hands the raw bytes back.
+    ///
+    /// **Placement is the caller's**, deliberately. This used to write the file
+    /// into the server's own `data/images/` and return that host path to
+    /// the model — a path in nobody's vocabulary: it is not the caller's home,
+    /// not their container, and every consumer downstream resolves agent paths
+    /// (§6). Telegram's `send_attachment` therefore looked for
+    /// `data/images/x.png` under the user's home and answered "file not found",
+    /// and `read_file`/`execute_cmd`/the viewer could not reach it either. The
+    /// manager has no `UserFs` and no session, so the one place that does — the
+    /// tool, through its `ToolContext` — owns where the image lands.
+    pub async fn generate_bytes(
         &self,
         provider_id:  &str,
         prompt:       &str,
         extra_params: Option<&serde_json::Value>,
-    ) -> Result<(PathBuf, String)> {
+    ) -> Result<Vec<u8>> {
         let provider = self.get(provider_id).await
             .ok_or_else(|| anyhow!("image provider '{}' not found", provider_id))?;
 
-        let images_dir = self.data_root.join("images");
-        tokio::fs::create_dir_all(&images_dir).await?;
-
         let bytes = provider.generate(prompt, extra_params).await?;
+        info!(provider_id, bytes = bytes.len(), "image generated");
 
-        let file_id: String = rand::rng()
-            .sample_iter(rand::distr::Alphanumeric)
-            .take(32)
-            .map(char::from)
-            .collect();
-        let path = images_dir.join(format!("{file_id}.png"));
-        tokio::fs::write(&path, &bytes).await?;
-
-        let url = format!("/api/images/{file_id}");
-        info!(provider_id, path = %path.display(), "image generated");
-
-        Ok((path, url))
+        Ok(bytes)
     }
 
     // ── Tool injection ─────────────────────────────────────────────────────────
@@ -236,10 +229,6 @@ impl ImageGeneratorManager {
         ]
     }
 
-    pub fn images_dir(&self) -> PathBuf {
-        self.data_root.join("images")
-    }
-
     // ── Private ───────────────────────────────────────────────────────────────
 
     async fn reload(&self) -> Result<()> {