[Ubuntu 24.04][Agent&Skills] Telegram bridge credential not injected into sandbox after channels add + rebuild

## Description

After running `channels add telegram` with a real, valid bot token and rebuilding, the Telegram bridge fails to start inside the sandbox. The bot token is registered with the OpenShell gateway and `channels add`/`rebuild` both report success, but the credential never reaches the sandbox runtime environment, so the bridge process never authenticates to Telegram.

Platform scope: Reproduced on Ubuntu 24.04 x86_64 cloud VM. Not attempted on other platforms.

Regression: Unknown — earlier versions not tested.

OpenShell issue: No — this is the same credential-binding gap tracked in #10079 for Discord, Slack, Google Chat, and Microsoft Teams. That issue's root-cause status table listed Telegram as not covered/not measured, and its fixes covered Discord, Slack, and Google Chat only. This report confirms Telegram remains unfixed, filed separately since #10079 has since been closed for the channels it did fix.

## Environment

```text
Device: Ubuntu 24.04 x86_64 cloud VM
OS: Ubuntu 24.04
Architecture: x86_64
OpenShell CLI: 0.0.106
NemoClaw: v0.0.118
OpenClaw: 2026.7.1
```

## Steps to Reproduce

1. Onboard a fresh OpenClaw sandbox to Ready.
2. Export a real, valid `TELEGRAM_BOT_TOKEN` and `TELEGRAM_ALLOWED_IDS`, then run:
```bash
nemoclaw {sandbox} channels add telegram
nemoclaw {sandbox} rebuild --yes
```
Both commands complete successfully with no error or credential warning.
3. Check the gateway logs:
```bash
nemoclaw {sandbox} logs --tail 200 | grep -i telegram
```
4. Check the runtime environment inside the sandbox:
```bash
docker exec {container} printenv | grep -i TELEGRAM
```

## Expected Result

The Telegram bridge starts, authenticates to the Telegram Bot API using the configured token, and `TELEGRAM_BOT_TOKEN` is present in the sandbox container's runtime environment.

## Actual Result

Step 3:
```text
[gateway] http server listening (2 plugins: nemoclaw, telegram; 1.4s)
[telegram] [default] DM allowlist configured (1 entry)
[telegram] [default] bridge did not start within 15s; check channels.telegram.enabled, plugin entries, and gateway log
```

Step 4: empty — `TELEGRAM_BOT_TOKEN` is not present in the sandbox runtime environment.

The bot token itself is valid — confirmed independently via a direct `getMe` call against Telegram's real API outside NemoClaw, which returns a valid bot identity. The failure is specific to NemoClaw's credential injection into the sandbox runtime, not the token or Telegram's API.

## Logs

```text
[gateway] http server listening (2 plugins: nemoclaw, telegram; 1.4s)
[telegram] [default] DM allowlist configured (1 entry)
[telegram] [default] bridge did not start within 15s; check channels.telegram.enabled, plugin entries, and gateway log
[telegram] [default] bridge did not start within 15s; check channels.telegram.enabled, plugin entries, and gateway log
```

## Related

Same credential-binding root cause tracked in #10079 for Discord, Slack, Google Chat, and Microsoft Teams. That issue's status table listed Telegram as not covered/not measured, and its fixes covered Discord, Slack, and Google Chat only.

Reproduce with `nemoclaw {sandbox} channels add telegram`, `rebuild --yes`, gateway logs, and `docker exec {container} printenv`, then read the related credential-binding work in #10079 and trace Telegram's sandbox credential path. Done means the valid token reaches the runtime environment after rebuild, the Telegram bridge authenticates, and the reported gateway checks no longer show the startup timeout.

Written by the indexing model from the issue text.