feat: self-hosted Telegram bridge for the SDK (Fixes #1426)

[Marcus-Mok-GH]

• Adds sdk/examples/telegram-bot.ts: a dependency-free Telegram bridge that forwards chat messages to an agent run and replies with its text output, so cloud/free users can drive the agent from their phone instead of the website.
• Per-chat sessions: follow-ups pass previousRun to continue context; /new resets; messages queue per chat so runs never overlap.
• Zero new dependencies: plain fetch long-polling against the Telegram Bot API; agent id and working directory configurable via FREEBUFF_AGENT/FREEBUFF_WORKDIR.
• Documents usage in sdk/README.md (Example 3) and notes it in sdk/CHANGELOG.md.

Fixes #1426

Happy to adapt this to however the team would want a hosted version to work (auth, which agent ids to expose, etc.). Just let me know.

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

[codebuff-team]

Nice idea and a genuinely useful addition — a zero-dependency example showing how to drive an agent from Telegram fits well alongside the other SDK examples, and per-chat session/queueing logic in telegram-bot.ts is clean.

The main issue is robustness for something meant to run continuously: main()'s while (true) loop calls tg('getUpdates', ...) with no try/catch (lines ~58-60). tg() throws on any non-2xx/non-ok response or network error, and since main() at the bottom is invoked without a .catch(), any transient Telegram outage, rate limit, or DNS blip kills the whole bot silently (unhandled rejection). For a script whose entire pitch is 'run this and forget it,' that's the first thing that will bite a real user. At minimum wrap the getUpdates call in try/catch with a short backoff/retry, and add main().catch(...) with a non-zero exit or log.

Smaller things worth a look before this is portable:

• The default agent id codebuff/base@0.0.16 is version-pinned and will go stale; consider defaulting to the unversioned id or documenting that it needs updating.
• No handling for Telegram's 409 conflict (another poller running) or getUpdates timeout edge cases.
• Worth double-checking the event.type === 'text' / event.source shape against the current SDK event types — I can't verify from the diff alone that this matches the real handleEvent payload.

With the crash-on-network-error issue fixed this looks like a solid, mergeable example.