feishu: allow bot-to-bot messages in groups (allowlisted bot senders + hop limit)

Summary

Feishu does deliver bot-authored @ mentions to the receiving bot's app when the app has im:message.group_at_msg.include_bot:readonly (获取群组中其他机器人和用户@当前机器人的消息). The platform delivers the event; channels/feishu/runtime.py then drops it unconditionally:

# Skip bot messages
if sender.sender_type == "bot":
    return

So a second bot can never trigger a nanobot, and there is no configuration that changes this. Upstream main has no relevant option either — nanobot/channels/feishu/config.py only exposes allow_from / group_policy (verified against main).

Related: #3772 (same user-visible symptom, closed on the assumption that Feishu excludes bot messages "by design" — that is only true for apps that lack the include_bot permission), and the Discord precedent already merged for the same class of problem: #3280 "fix(discord): allow bot-to-bot messaging, only drop self-loops".

Evidence (two hosts, latest release v0.3.5)

App scopes as reported by GET /open-apis/application/v6/applications/:app_id (the platform's own list, not a doc reading):

im:message.group_at_msg:readonly                 获取群组中用户@机器人消息
im:message.group_at_msg.include_bot:readonly     获取群组中其他机器人和用户@当前机器人的消息   <-- granted
im:message.group_msg                             获取群组中所有消息                          <-- not granted (restricted)
im:message:send_as_bot                           以应用的身份发消息

Gateway log on host A when bot B (a separate Feishu app, different machine) @-mentioned it:

FEISHU-DIAG recv sender_type=bot sender=ou_08c7fc05… chat=oc_8526… chat_type=group msg_type=text
mentions=[{'key': '@_user_1', 'name': 'CLI_101', 'open_id': 'ou_8e111fcf…', 'user_id': None}]

→ event delivered, sender_type == "bot" → dropped. With the guard temporarily relaxed in a local build, the very same message was processed normally, and the reverse direction behaved identically. So the only missing piece is this early return.

Proposal (mirrors the Discord fix)

Add explicit, opt-in config to channels.feishu.instances[]:

"allowBotSenders": ["ou_xxx"],  // [] = current behaviour (drop all bot messages); "*" = any bot
"botHopLimit": 2,               // max consecutive bot-triggered turns per chat; human message resets it
"replyWithMention": false       // when replying to an allowlisted bot, use Feishu's mention syntax

Behaviour:

1. sender_type == "bot" + open_id in allowBotSenders → process as usual (in groups, no @ needed when include_bot is granted; the mention still counts as addressed to the bot).
2. Any other bot sender → keep the current drop.
3. botHopLimit prevents two bots from ping-ponging (nothing in the current loop guard covers channel-level message hops; defaults.max_tool_iterations cannot).
4. replyWithMention: true sends the reply as text <at user_id="ou_xxx"></at> … (or a card {"tag": "at", "user_id": …} element), because Feishu only routes group messages that mention the target bot.

Why it matters

include_bot exists precisely for multi-bot groups, and the platform side already works. Today the only way to get multiple bots cooperating in one group is a local, upgrade-fragile monkey patch, because the client silently discards what the platform delivered.