Bot channels can report startup failure while Telegram and Discord are already listening

### What happened

When starting a Telegram or Discord bot channel in Maka Desktop, the UI can show a failure toast saying that the bot started but did not enter listening mode:

- `Telegram 启动后未进入监听`
- `Discord 启动后未进入监听`

In both cases, the bot was subsequently able to receive a test message and send the expected reply. The startup diagnostic therefore does not match the eventual runtime state and can make a successfully configured channel look broken.

Expected behavior: keep the channel in a connecting state until the listener is ready, or clear/reconcile the transient startup warning once the listener becomes operational. A failure toast should only remain when the channel cannot receive messages.

### How to reproduce

1. Configure a Telegram Bot channel and start it from Maka Desktop.
2. Observe the startup status shortly after enabling the channel.
3. If the `Telegram 启动后未进入监听` toast appears, send a direct test message to the bot.
4. Observe that the bot can still receive the message and return the expected text.
5. Repeat the same flow with a Discord Bot channel and a test-server message mentioning the bot.
6. Observe the same transient `Discord 启动后未进入监听` toast followed by a successful message round trip.

The behavior was observed during manual smoke testing on 2026-09-10 for both channels.

### Environment

- Maka version or commit: `0.2.0-dev.26.20260909` (packaged nightly)
- OS and version: Windows 10, `10.0.19045`, x64
- Surface: Desktop
- Locale: `zh-CN`
- Electron: `43.4.1`
- Chrome: `150.0.7871.224`
- Node.js: `24.18.1` (packaged runtime)
- Affected channels: Telegram and Discord

### Logs, screenshots, or additional context

The two desktop diagnostic reports had the titles above. The observed successful follow-up replies were exact-text smoke messages in the respective channels.

The Discord test used the Discord web client. Because Discord Gateway access required a system-level TUN route in this mainland-China network environment, the report focuses on the readiness-state mismatch rather than treating the network setup as the defect.

No bot tokens, user IDs, or raw provider payloads are included. Suspected area: a startup/readiness race where the UI reports failure before the listener reaches its ready state.