feat(channel): implement wiki access for FeishuChannel

**Background**

#2464 added DingTalk knowledge base access and, with it, a shared contract on `ChannelBase`:

- `list_wiki_spaces` / `list_wiki_nodes` / `read_wiki_document`, returning the platform-neutral `WikiSpace` / `WikiNode` / `WikiPage` / `WikiDocument`
- `ChannelCapability.wiki`, which a channel sets to declare it has a wiki
- The three agent tools (`ListWikiSpaces`, `ListWikiNodes`, `ReadWikiDocument`) in `channel/_tools`, equipped by `ChannelBase.list_tools` for any channel that declares the capability

So a second platform only has to implement the three methods and flip the flag. The tools, the private-chat restriction and the tool wiring are already generic: `ChatService` only hands a channel the sender's identity when the session is a 1:1 chat, and `FeishuChannel.list_tools` already returns `super().list_tools(...)` alongside its own tools.

Feishu models a wiki the same way DingTalk does — knowledge spaces, a node tree, and documents made of blocks — so it is the natural second implementation.

**Changes**

- Set `wiki=True` on `FeishuChannel.capabilities`.
- Implement the three methods on `FeishuChannel`, mapping Feishu's API onto the neutral models:
- `list_wiki_spaces` ← `GET /open-apis/wiki/v2/spaces`
- `list_wiki_nodes` ← `GET /open-apis/wiki/v2/spaces/{space_id}/nodes` (`parent_node_token`)
- `read_wiki_document` ← `GET /open-apis/wiki/v2/spaces/get_node` for the node, then `GET /open-apis/docx/v1/documents/{document_id}/blocks`
- Handle the node indirection: a Feishu wiki node points at an underlying object through `obj_token` / `obj_type`, so `WikiNode.is_document` should only be true for the object types the block reader understands (`docx`), and the read path has to resolve `obj_token` before fetching blocks.
- Render the Feishu block types to Markdown, the way the DingTalk implementation does for headings, paragraphs, lists, quotes and tables.
- Tests covering the three methods, the node mapping, and that the tools are not equipped when the capability is off.

**Note**

The open question is identity, and it should be settled before implementation starts.

The contract requires every wiki call to act as the message sender, so the platform applies that user's own permissions. DingTalk supports this directly: an `operatorId` on an app-token request scopes the read to that user.

Feishu has no equivalent. `GET /open-apis/wiki/v2/spaces` accepts `tenant_access_token` or `user_access_token`, has no parameter naming an operator, and with a tenant token returns the spaces **the app** can access, not the ones the sender can. Two options:

- Obtain a `user_access_token` per channel user through Feishu's OAuth flow and store it with its refresh token. This preserves the security model but adds a per-end-user credential mechanism the app does not have today.
- Read with the tenant token and accept that the agent sees whatever the app was granted. This drops the per-user guarantee the contract is built on, so it would need to be an explicit, documented decision rather than a silent one.