The bot now monitors all DAG runs and sends AI-generated notifications
when they complete. Instead of fixed template messages, the AI agent
analyzes the run results (status, errors, step details) and writes
a contextual, helpful notification message.

- New DAGRunMonitor polls for completed DAG runs every 10 seconds
- On completion, creates a temporary agent session to generate the message
- Falls back to a simple status message if the agent is unavailable
- Notifications sent to all allowed Telegram chats
- Seeds seen-set on startup to avoid notifying about old runs

Add 'waiting' to monitored statuses so the bot proactively notifies
when a DAG needs human approval. The AI agent generates an urgent
message highlighting which steps are waiting for action.

Show why the AI agent couldn't generate a notification so the user
can diagnose configuration issues (e.g., no model configured).

- Increase agent response timeout from 30s to 60s
- Disable safe mode for notification sessions since the agent only
  needs to write a message, not execute tools. Safe mode could cause
  the agent to hang waiting for command approval with no one to approve.

The monitor now runs in the server process and uses the same agent API
instance as the web UI. This ensures the agent has proper model config,
tools, and session management. Previously it created a separate agent
API that wasn't working correctly.

- Add Server.AgentAPI() getter to expose the agent API
- Remove initTelegramBot() which created a duplicate agent API
- Initialize Telegram bot after server, using server.AgentAPI()
- Handle nil agentAPI gracefully (falls back to simple notifications)

The latestAssistant variable was declared inside the poll loop, so it
reset to empty on every tick. If the assistant message arrived while
Working was still true, the next poll (when Working became false) saw
no new messages and latestAssistant stayed empty — hanging forever.

Fix: move latestAssistant outside the loop and scan all messages on
each poll instead of only new ones.

Two fixes for 'prompt expired or already answered' error:

1. Don't process historical messages when subscription starts.
   Previously, subscribeLoop replayed ALL session messages on startup,
   including already-answered prompts. Now it only tracks new messages.

2. Only show prompt buttons when HasPendingPrompt is true in the
   session state, preventing stale prompts from being displayed.

Previously the monitor created a throwaway session with a system user
for each notification, so the user couldn't ask follow-up questions.

Now each notification creates a session with the Telegram user's
identity and adopts it as the chat's active session. After receiving
the notification, the user can immediately ask "show me the logs",
"retry it", etc. and the agent remembers the DAG context.

Automatically start a fresh session when total token usage reaches
50% of the context limit (default 200k tokens). Prevents the agent
from hitting context window errors during long conversations.

Instead of losing all context on rotation, the last 3 user/assistant
exchanges are extracted from the old session and prepended to the
user's new message. This gives the agent enough context to continue
the conversation naturally without hitting the context limit.

- Define AgentService interface in telegram package with the 5 methods
  the bot uses, replacing direct *agent.API dependency
- Replace Server.AgentAPI() getter with WithAgentAPICallback option so
  the server no longer permanently exposes its internal agent API
- Require AllowedChatIDs to be non-empty, preventing open access

Previously each sendMessage call cancelled the existing subscription
and started a new one, causing responses to be lost when messages
were sent consecutively. Now ensureSubscription() checks if a
subscription is already running for the session and skips if so.
Only session creation and adoption force a new subscription.

…ant DAGs

The pub-sub delivers StreamResponse without SessionState, so
hasPendingPrompt was always false and prompts were never shown.
Fix by showing prompts whenever a UserPrompt message arrives.

1. Skip Telegram bot when agentAPI is nil to avoid typed-nil panic
2. Add missing DAGStore initialization in standalone telegram command
3. Add env var bindings (DAGU_TELEGRAM_TOKEN, etc.) for config loader
4. Store owning userID in chatState and reuse for all agent API calls
   instead of rebuilding identity from chat/callback IDs
5. Remove Markdown parse mode from prompt messages to avoid breaking
   on special characters in agent output
6. Move markSeen after notification delivery succeeds so transient
   failures are retried on the next poll
7. Remove unused userIdentityFromCallback method

The Telegram bot now starts in both `dagu server` and `dagu start-all`,
using the server's agent API. This removes the standalone `dagu telegram`
command which created a separate agent API that was missing DAGStore
and other configuration.

- Add Telegram bot startup to runServer using WithAgentAPICallback
- Remove internal/cmd/telegram.go
- Remove Telegram command registration from main.go
- Remove ServiceTelegram from config loader

Restructure config from `telegram.*` to `bots.*` so future bot
integrations (Slack, Discord, etc.) share a common namespace.
`safe_mode` is now a shared field under `bots`, while
Telegram-specific fields live under `bots.telegram`.

Env vars change from DAGU_TELEGRAM_* to DAGU_BOTS_TELEGRAM_*.

Only one bot can be active at a time. The `bots.provider` field
selects which bot to start ("telegram", etc.). If empty, no bot
starts. Env var: DAGU_BOTS_PROVIDER.