- Add telegram.rs: TelegramGateway with long-polling, message splitting,
  typing indicators, bot validation via getMe
- Refactor GatewayHandler to hold Arc<dyn Gateway> instead of taking
  &dyn Gateway per call — enables spawning handler tasks per message
- Add create_gateway() factory function in mod.rs
- Add GatewayStatus/PairedUserInfo types and status() method to manager
- Enhance pairing store list_paired_users to include paired_at timestamp
- Add unpair_user and already-running check to manager
- 14 tests passing (9 telegram split_message + 5 pairing)

- Add routes/gateway.rs with 5 endpoints:
  POST /gateway/start, POST /gateway/stop, GET /gateway/status,
  POST /gateway/pair, DELETE /gateway/pair/{platform}/{user_id}
- Add GatewayManager to AppState, initialized in AppState::new()
- Register gateway routes in routes/mod.rs configure()
- Add mod gateway to main.rs for binary target
- All 14 tests passing, clippy clean, formatted

- Add GatewaySettingsSection.tsx with full gateway management:
  - Gateway list with running status and paired user count
  - Add Gateway modal (Telegram bot token input with BotFather link)
  - Stop gateway button
  - Generate Pairing Code with countdown timer modal
  - Paired users list with unpair button per user
  - Auto-refresh status every 5 seconds
- Add 'Gateways' tab to SettingsView between Keyboard and App
- Regenerate openapi.json and types.gen.ts for SessionType::Gateway
- TypeScript clean, ESLint clean

The gateway handler was creating sessions and calling agent.reply()
without ever setting up a provider, causing 'provider not set' errors.

Two changes:

1. complete_pairing() now stores the current provider name, model config,
   and default extensions on the session at pairing time — matching what
   start_agent does for regular sessions.

2. relay_to_session() now calls restore_provider_from_session() and
   load_extensions_from_session() before agent.reply() — handling both
   fresh agents and agents evicted from the LRU cache.

Gateway configs were only held in-memory and lost on app restart.

Changes:
- GatewayManager now persists configs using goose's config system:
  - Non-secret gateway metadata (gateway_type, max_sessions) stored via
    Config::set_param('gateway_configs') as a YAML list
  - Platform secrets (bot tokens etc) stored via Config::set_secret()
    keyed as 'gateway_platform_config_{type}'
- start_gateway() saves config after successful start
- stop_gateway() removes saved config (gateway won't auto-start)
- check_auto_start() loads saved configs and starts gateways on launch
- Server startup (commands/agent.rs) spawns gateway auto-start task
  alongside the existing tunnel auto-start

- Remove standalone Gateways tab from SettingsView.tsx
- Render GatewaySettingsSection in AppSettingsSection.tsx right after
  TunnelSection — both connectivity features in the same place
- GatewaySettingsSection checks GET /tunnel/status on mount and returns
  null when tunnel state is 'disabled' (GOOSE_TUNNEL=no), matching
  TunnelSection's visibility behavior

GatewaySettingsSection was checking tunnel status independently using
gatewayFetch('/tunnel/status') which may have silently failed, causing
the component to not render.

Fix: moved the tunnel-disabled check into AppSettingsSection using the
SDK's getTunnelStatus() (same method TunnelSection uses). Both
TunnelSection and GatewaySettingsSection are now conditionally rendered
together by the parent — neither renders when GOOSE_TUNNEL=no.

- Add Gateway tab with Radio icon between Keyboard and App tabs
- Gateway tab contains TunnelSection + GatewaySettingsSection
- Hide Gateway tab entirely when tunnel is disabled (GOOSE_TUNNEL=no)
- Remove TunnelSection/GatewaySettingsSection from AppSettingsSection
- Check tunnel status on mount via getTunnelStatus API

…state

- Default tunnelDisabled to false so tab shows immediately
- Only hide when API explicitly returns state: 'disabled'
- On API error/timeout, keep tab visible (fail open)
- Simplify conditionals from === false to !tunnelDisabled

Gateway sessions are long-lived, but the user may change their provider,
model, or extensions in the desktop settings at any time. Previously the
session was configured once at pairing time and never updated, so gateway
chats could use stale config (wrong provider, missing extensions).

Now, on each incoming Telegram message, relay_to_session calls
sync_session_config which:

1. Reads the current global config (provider, model, extensions)
2. Compares with what's stored on the session
3. If anything changed, updates the session in the DB
4. If extensions changed, tears down the old agent (removing stale
   extension processes) so a fresh agent is created

After sync, the session is re-read and restore_provider_from_session +
load_extensions_from_session pick up the current values. When nothing
has changed the sync is a no-op — no DB writes, no agent recreation.

…ream

Two issues fixed in relay_to_session:

1. Typing indicator keepalive: Telegram stops showing 'typing...' after
   ~5 seconds. When the agent is doing tool calls (file listing, etc.),
   the stream can take much longer. Now a background task re-sends the
   typing indicator every 4 seconds, cancelled when the stream finishes
   or errors. This ensures the user always sees activity in the chat.

2. Debug logging: Added structured debug logs for every AgentEvent in
   the stream — message events (with role + content count), tool
   requests/responses, MCP notifications, model changes, history
   replacements, and stream completion (with event count + response
   length). This makes it possible to diagnose 'no response' issues
   from server logs.

Also: the stream loop now emits ToolStarted/ToolCompleted messages to
the gateway for assistant ToolRequest/ToolResponse content. For Telegram
this translates to additional typing indicators (ToolStarted) which
further keeps the UI responsive during multi-step tool interactions.

Two fixes for multi-turn tool-calling sessions feeling unresponsive:

1. Set max_turns to 5 for gateway sessions. Previously None (default
   1000), so the agent could do dozens of tool-call round-trips before
   responding. Now after 5 LLM→tool turns it stops and replies with
   what it has, asking the user if they want to continue.

2. Send assistant text to Telegram as it arrives instead of buffering
   everything until the stream ends. When a ToolRequest follows text
   in the same message, the text is flushed immediately — the user
   sees 'Let me check...' right away, then the typing indicator while
   tools run, then the next response as a separate message. Only the
   final trailing text (after the last tool round-trip) waits for
   stream end.

   Before: user waits 30+ seconds seeing only 'typing', gets one
   giant message at the end (or nothing if it times out).

   After: user sees incremental messages as the agent works through
   each step, with clear activity indicators between them.

* origin/main: (42 commits)
  fix: use dynamic port for Tetrate auth callback server (#7228)
  docs: removing LLM Usage admonitions (#7227)
  feat(otel): respect standard OTel env vars for exporter selection (#7144)
  fix: fork session (#7219)
  Bump version numbers for 1.24.0 release (#7214)
  Move platform extensions into their own folder (#7210)
  fix: ignore deprecated skills extension (#7139)
  Add a goosed over HTTP integration test, and test the developer tool PATH (#7178)
  feat: add onFallbackRequest handler to McpAppRenderer (#7208)
  feat: add streaming support for Claude Code CLI provider (#6833)
  fix: The detected filetype is PLAIN_TEXT, but the provided filetype was HTML (#6885)
  Add prompts (#7212)
  Add testing instructions for speech to text (#7185)
  Diagnostic files copying (#7209)
  fix: allow concurrent tool execution within the same MCP extension (#7202)
  fix: handle missing arguments in MCP tool calls to prevent GUI crash (#7143)
  Filter Apps page to only show standalone Goose Apps (#6811)
  opt: use static for Regex (#7205)
  nit: show dir in title, and less... jank (#7138)
  feat(gemini-cli): use stream-json output and re-use session (#7118)
  ...

When a gateway is stopped (stop_gateway or stop_all), all pairings
for that platform are removed from the database. Users must re-pair
on next start. Makes sense for Telegram where pairings are tied to
a running goose session.

Stop now keeps the saved config (bot token) so the gateway can be
restarted without re-entering credentials. Pairings are still cleared
on stop so users must re-pair.

Three states in the UI:
- Unconfigured: shows token input + Start
- Configured + stopped: shows Start button + trash to remove
- Running: shows Pair Device + Stop

New API endpoints:
- POST /gateway/restart - restart a stopped gateway from saved config
- POST /gateway/remove - stop + delete saved config entirely

Status endpoint now includes configured-but-stopped gateways.

Cleaned up the telegram card to three clear states:
- No config: shows token input + Start
- Stopped (has saved config): shows Start + trash to remove
- Running: shows Pair Device + Stop

Start after stop calls /gateway/restart which uses the saved token.
No need to re-enter it.

* main:
  fix: handle reasoning_content for Kimi/thinking models (#7252)
  feat: sandboxing for macos (#7197)
  fix(otel): use monotonic_counter prefix and support temporality env var (#7234)
  Streaming markdown (#7233)
  Improve compaction messages to enable better post-compaction agent behavior (#7259)
  fix: avoid shell-escaping special characters except quotes (#7242)

…messages