Telegram Bot listener times out with TUN disabled; proxy environment variables restore message reception

### What happened

## Summary

Telegram Bot credential verification succeeds, but the message listener fails to start when TUN mode is disabled, despite a working HTTP proxy being configured in Maka's network settings.

I send messages to the Bot from my phone, and Maka runs on my Mac. The affected connection is between Maka on the Mac and Telegram—not the phone's connection.

Observed behavior:

- **TUN enabled:** The Bot works.
- **TUN disabled, normal Maka launch, UI proxy enabled:** Telegram listener startup fails with `Fetch timeout`.
- **TUN disabled, explicit proxy test using curl:** The Telegram API domain responds successfully.
- **TUN disabled, Maka launched with proxy environment variables:** Maka successfully receives messages sent to the Bot.

The network settings explicitly state that the proxy applies **only to AI model requests**. This may therefore be a missing Telegram proxy configuration path rather than a defect in the existing model proxy feature.

## Actual Behavior

Credential verification succeeds. The notification says, translated from Chinese:

> Telegram credentials verified. Credential check passed. This does not mean the message send/receive service has started.

Starting the Telegram service then produces:

> Telegram did not enter the listening state after startup. See logs for runtime details.

Relevant logs:

```text
[2026-09-09T07:43:20.697Z] WARN [bots:telegram] timeout: Fetch timeout
[2026-09-09T07:43:26.184Z] WARN [bots:telegram] connection_failed: Fetch timeout
[2026-09-09T07:43:26.192Z] WARN [bots:telegram] bot_connection_failed: Fetch timeout
```

Neither `401 Unauthorized` nor `409 Conflict` appears in the provided logs.

## Expected Behavior

Please provide a supported way to configure Telegram Bot proxy access through Maka's UI, either by:

1. Adding a dedicated Telegram proxy setting; or
2. Adding an explicit option for Bot connections to reuse the existing proxy configuration.

The configured proxy should cover the relevant Telegram operations, including credential verification, listener startup, ongoing message reception, and outgoing messages.

If model and Bot proxy settings are intentionally separate, the Telegram settings should explain this and provide actionable configuration instructions.

Users should not need to enable TUN or maintain a custom command-line launcher to use a Bot through an otherwise working local proxy.

## Additional Diagnostic Context

Report capture time: `2026-09-09T07:43:39.167Z`.

The same report contains the following entries, but their relationship to the Telegram failure has not been established:

```text
[2026-09-09T07:43:09.730Z] ERROR [runtime-host] Direct peer is unavailable: Error: Invalid peer reachability directRoutes

[2026-09-09T07:43:10.686Z] ERROR (node:31497) [DEP0180] DeprecationWarning: fs.Stats constructor is deprecated.

[2026-09-09T07:43:11.134Z] ERROR Error occurred in handler for 'sessions:observe': Error: Session observation ended before it became ready
```

Runtime Host diagnostic summary:

```text
Recent local Runtime Host process exits (0)

Runtime Host
Diagnostics unavailable: No Runtime Host authority was associated with this error
```

## Questions for the Maintainers

- Do credential verification and message listening use different networking implementations or proxy configurations?
- What is the supported way to configure a Telegram proxy in this version?
- Could connection errors indicate whether the failing connection is direct or proxied, with credentials redacted?

## User Impact

The working command-line workaround requires maintaining proxy settings separately from Maka's UI and does not automatically apply to subsequent normal launches from the Dock. This is cumbersome for users unfamiliar with terminal commands.

### How to reproduce

## Preconditions

- A local HTTP proxy is available at `127.0.0.1:7890`.
- The proxy client remains running throughout the tests.
- TUN mode is disabled.
- A Telegram Bot is configured in Maka.
- The issue was observed in an environment where normal listener startup fails without TUN, while explicit proxy access to Telegram succeeds.

## Reproduction Steps

1. Fully quit Maka.
2. Keep the local proxy client running, with TUN disabled.
3. Launch Maka normally, without explicitly supplying proxy environment variables.
4. Open **Settings → General → Network** and configure:
- Proxy server: Enabled.
- Protocol: HTTP/HTTPS.
- Address: `127.0.0.1`.
- Port: `7890`.
- Proxy authentication: Disabled.
5. The proxy bypass field displays `metaso.cn, baidu.com`. Do not manually add Telegram domains to the bypass list.
6. Run Telegram Bot credential verification.
7. Observe that credential verification succeeds.
8. Start the Telegram service.
9. Observe the listener startup failure and `Fetch timeout` logs.

The network settings description states that the proxy applies only to AI model requests.

## Control Test: Verify the Proxy Without TUN

With TUN still disabled, run:

```bash
/usr/bin/curl \
--proxy http://127.0.0.1:7890 \
--noproxy "" \
--connect-timeout 10 \
--max-time 20 \
-I https://api.telegram.org
```

Observed response:

```text
HTTP/1.1 200 Connection established

HTTP/2 302
server: nginx/1.30.0
location: https://core.telegram.org/bots
```

This confirms that the local proxy can establish an HTTPS connection to the Telegram API domain without TUN.

This test does not use a Bot Token and does not validate authenticated Bot API calls or sustained long polling.

## Workaround Test: Launch Maka With Proxy Environment Variables

1. Fully quit Maka.
2. Keep TUN disabled and the proxy client running.
3. Launch Maka using:

```bash
env \
HTTP_PROXY=http://127.0.0.1:7890 \
HTTPS_PROXY=http://127.0.0.1:7890 \
NODE_USE_ENV_PROXY=1 \
/Applications/Maka.app/Contents/MacOS/Maka
```

4. Restart the Telegram connection in Maka.
5. Send a message to the Bot from the phone.

**Observed result: Maka successfully receives the message.**

Verification limits:

- All three environment variables were supplied together; they were not tested individually.
- Incoming message reception was confirmed. Full reply delivery and long-term stability were not documented.
- This workaround only applies to this launch; it does not persist the environment variables for normal launches from the Dock.

## Comparison

| Configuration | Observed result |
|---|---|
| TUN enabled | Bot works |
| TUN disabled; normal launch; UI proxy enabled | Listener startup fails with `Fetch timeout` |
| TUN disabled; curl explicitly uses the local proxy | Telegram domain responds over HTTPS |
| TUN disabled; launch with proxy environment variables | Incoming Bot message reception succeeds |

These observations are consistent with the listener not using the UI-configured proxy during a normal launch, but the exact implementation-level cause has not been established.

### Environment

| Item | Value |
|---|---|
| Maka version | `0.2.0-dev.25.20260908` |
| Build | `packaged` |
| Update channel | `nightly` |
| Operating system | macOS |
| OS version reported by diagnostics | `darwin 25.6.0` |
| Architecture | `arm64` (Apple Silicon) |
| Electron | `43.4.1` |
| Chrome | `150.0.7871.224` |
| Node | `24.18.1` |
| UI locale | `zh-CN` |
| Proxy protocol configured in Maka | HTTP/HTTPS |
| Local proxy address | `127.0.0.1` |
| Local proxy port | `7890` |
| Proxy authentication | Disabled |
| Proxy client name and version | Not recorded |

Maka runs on the Mac, while messages are sent to the Telegram Bot from a phone.

The local proxy client remains running with TUN disabled during the failing case and the successful environment-variable workaround. Enabling TUN also allows the Bot to work.

### Logs, screenshots, or additional context

_No response_