feat(feishu): bind credentials through participants

[GatewayJ]

Summary

• Bind Feishu credentials through participants and remove the dedicated Feishu config store path.
• Add participant binding CLI/API/client support and Feishu participant provider wiring.
• Update Feishu setup docs, embedded skills, and runtime design notes.

[xxx7xxxx]

Isn't FeishuKind too specific for a general structure? Propose ParticipantType or so to align with type in Participant.

[xxx7xxxx]

The new bind flow stores two different Feishu participant shapes: agent participants carry app credentials in channel_app_config, while the admin human carries only channel_user_kind=open_id and channel_user_ref=ou_xxx. Feishu can mention a human by open_id; the sender app config is required to send the message, but the human target should not need its own app config.

This path still treats every mention target as app-backed: SendMessage resolves mention_id through appConfigForMentionLocked, and defaultSendMessage then fetches a bot open_id from that target app. That works for agent participants, but mention_id=admin fails before send because the human participant has no app config.

Proposal: resolve mention targets through the participant model first. For type=human + channel_user_kind=open_id, use channel_user_ref as the Feishu at-user open_id. For type=agent, keep resolving the bot open_id from its app config. Please add focused coverage for agent -> admin human mention and keep the existing agent -> agent mention behavior.

[xxx7xxxx]

This event target set includes the participant id and channel_user_ref, but app-backed Feishu agents have no channel_user_ref. Real Feishu mention events normally carry the bot open_id, so /channels/feishu/participants/{id}/events may miss real @agent events unless the target set also includes the resolved bot open_id or inbound Feishu mentions are normalized to participant IDs before filtering.

[RussellLuo]

This package does not introduce a new channel; it implements a participant-backed provider for the existing Feishu channel. Keeping it under internal/channel/feishuparticipant makes the directory layout read like a new channel module. Would it be clearer to move this into internal/channel/feishu, for example as participant_provider.go or participant.go, so the package structure matches the actual responsibility?

[RussellLuo]

This now masks app_secret as the string present, which is fine locally, but the masking convention looks like an API boundary concern rather than a one-off handler detail. Since the same redaction semantics may need to stay consistent across API responses, CLI output, docs, and tests, would it be better to centralize this representation behind a shared constant or helper instead of hardcoding the literal here?