Fix podcasts defaulting to English: set language=de on default episode profiles

The three bundled episode profiles (business_analysis, solo_expert,
tech_discussion) shipped with language=null, which podcast_creator treats as
"unspecified" and defaults to English for outline/transcript generation
regardless of source language. Set language="de" on all three.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

BEDIENUNGSANLEITUNG.md

@@ -272,6 +272,22 @@ Das Episode- oder Sprecherprofil verweist auf ein Modell ohne konfiguriertes Cre
 `PUT /api/speaker-profiles/{id}` (`voice_model`) auf registrierte lokale/OpenRouter-Modelle
 umstellen — siehe `scripts/setup_models.sh` für die IDs der Standardmodelle.
 
+### Podcast wird auf Englisch statt Deutsch erzeugt
+
+Das verwendete Episode-Profil hat kein `language`-Feld gesetzt — ohne Angabe generiert das
+Sprachmodell standardmäßig auf Englisch, unabhängig von der Sprache der Quelle. Prüfen und
+korrigieren:
+
+```bash
+curl -s http://127.0.0.1:5055/api/episode-profiles | python3 -c \
+  "import json,sys; [print(p['name'], p['language']) for p in json.load(sys.stdin)]"
+```
+
+Fehlt `de`, per `PUT /api/episode-profiles/{id}` (vollständiger Body nötig, siehe oben)
+`"language": "de"` ergänzen. Die drei mitgelieferten Profile (`business_analysis`,
+`solo_expert`, `tech_discussion`) sind bereits korrigiert; bei neu angelegten eigenen Profilen
+selbst daran denken.
+
 ### Weitere technische Details
 
 Siehe [`CLAUDE.md`](CLAUDE.md) — dort stehen alle bisher aufgetretenen Probleme mit exakter

CLAUDE.md

@@ -41,6 +41,14 @@ A separate local `llama.cpp` server exists on this machine (managed via `~/llama
 
 **Chat model context window:** the Ollama credential used for `qwen3.5:27b` (`credential:di8b31l16zikyyb6isyi`) has `num_ctx=98304` set explicitly. Without this, esperanto's `OllamaLanguageModel` silently defaults `num_ctx` to **8192** regardless of the model's real capability or `OLLAMA_CONTEXT_LENGTH` — any chat context (e.g. "full content" mode on a real document) beyond that gets truncated by Ollama, and because `qwen3.5:27b` is a thinking model, the truncated prompt frequently produces an empty final answer (the response is silently swallowed by `clean_thinking_content`) instead of a visible error — looks exactly like "chat gives no answer" from the UI. `98304` is the largest value that still keeps the whole model on GPU 1 (`ollama ps` shows `100% GPU`); `131072` spills ~91% onto CPU and makes a single response take 5-6 minutes instead of ~1-2. Even at 98304, a full-book "Volltext" chat (~70k+ tokens of context) takes ~2-3 minutes — that's inherent to processing that much context on one consumer GPU, not a bug. For large documents, the default short/RAG context mode (only relevant chunks, not the whole document) stays fast; reserve "Volltext" for shorter sources. If `qwen3.5:27b` ever gets swapped for a different Ollama chat model, re-check this credential's `num_ctx` still makes sense for its VRAM footprint.
 
+**Podcast language:** the three bundled episode profiles (`business_analysis`, `solo_expert`,
+`tech_discussion`) ship with `language: null`, which the underlying `podcast_creator` library
+treats as "no language specified" and defaults to English for both outline and transcript
+generation — regardless of what language the source content or the briefing text is in. All
+three are set to `language: "de"` here. If you create a new episode profile, set `language`
+explicitly (`PUT /api/episode-profiles/{id}`, full body) — it doesn't inherit from the notebook
+or the source.
+
 ### Text-to-speech / speech-to-text
 
 Open Notebook's `openai_compatible` provider type talks to any endpoint implementing OpenAI's audio API shape (`POST /audio/speech`, `POST /audio/transcriptions` — see `esperanto.providers.tts.openai_compatible` / `.stt.openai_compatible` inside the app container for the exact contract). Since neither Ollama nor OpenRouter support TTS/STT, two thin wrapper servers in `services/` expose the locally installed tools this way: