[Bug]: Discord channel helpers crash before the client is ready

## Problem

`DiscordChannel` exposes best-effort management/context helpers such as `list_bot_chats`, `chat_name`, and `chat_kind`. These helpers currently assume the Discord client has already been initialized and that platform channel lookup succeeds.

However, `ChannelLifecycleDispatcher._start()` registers a channel instance immediately after scheduling `start_listening()`. During that startup window, `DiscordChannel._client` is still `None`, but the management API can already call `GET /channels/{channel_id}/chat_ids`, which delegates to `list_bot_chats()`.

`ChatService` also calls `chat_kind()` and `chat_name()` when building context for channel-bound sessions. If the Discord client is not ready, or if `fetch_channel()` fails for an unresolved chat id, these optional helpers can raise and fail the current request/run instead of treating the chat as unknown.

## Reproduction

On current `main` (`29b592358c2e983a0d10dd5227316b7a02d8c23a`), constructing a `DiscordChannel` without starting the gateway client and calling the helper methods produces:

- `list_bot_chats()` -> `AttributeError: 'NoneType' object has no attribute 'guilds'`
- `chat_name("123")` -> `AttributeError: 'NoneType' object has no attribute 'get_channel'`
- when `fetch_channel()` raises, `chat_name()` propagates that exception

## Expected behavior

These helpers are optional/best-effort. When the Discord client is not ready or a channel lookup fails, they should fail open:

- `list_bot_chats()` returns `[]`
- `chat_name(...)` returns `""`
- `chat_kind(...)` returns `None`

This matches the base channel helper contract and prevents management/API context paths from failing on transient Discord availability.

## Proposed scope

Keep the change focused to Discord helper behavior and regression coverage. Do not implement Discord agent tools or change message send/listen behavior.