[Feat] Add grant request card for blocked mentions

[nil-err]

Summary

This PR fixes the silent failure path for bot-to-bot handoffs in groups when an external bot @mentions the current bot but has not yet been granted talk access.

Previously, the human-message path already had a self-service /grant request card: if a person explicitly @mentioned the bot but failed the canTalk gate, BotMux would notify the owner with an approval card. The foreign-bot path used a separate gate, however. If the sender was not a known same-deployment peer, was not in this bot's oncall chat, and did not match chatGrants or globalGrants, the dispatcher simply returned without any visible feedback. That made bot-to-bot collaboration look broken until an owner manually ran /grant @bot.

What Changed

• Added an autoGrantRequestCards bot config field.
  • Default behavior is enabled for backward-compatible discoverability.
  • false explicitly disables automatic grant request cards and keeps the old silent-drop behavior.
• Reused the existing grant request card flow for blocked external bot @mentions.
  • The card is still sent only to the owner path.
  • It uses the existing pending/deny throttling, so repeated blocked @mentions do not spam cards.
  • It grants talk-only access through the existing grant_chat / grant_global actions.
• Kept the authorization model unchanged.
  • The blocked message is not routed into a CLI session.
  • A granted sender receives only canTalk access.
  • Sensitive operations such as /restart, /close, terminal write access, and config mutation remain governed by allowedUsers / owner permissions.
• Added a Dashboard control in Bot Profiles -> Authorization & Quota.
  • New label: Auto grant card for blocked @mentions / 未授权 @ 自动弹授权卡.
  • Toggling it updates grant prefs through the existing dashboard proxy and daemon IPC path.
• Updated bots-json docs in both zh/en to document the new field.
• Adjusted grant request wording from user-specific language to sender/object language so the card also reads correctly for bot senders.

Root Cause

BotMux had two different inbound routing paths:

1. User-originated group messages used checkGroupMessageAccess(). When a user explicitly @mentioned the bot but failed canTalk, the dispatcher called maybeSendGrantRequestCard().
2. Bot-originated group messages used the foreign-bot gate. Unknown external bots were intentionally blocked unless they were a known peer, oncall participant, chatGrant, or globalGrant. That gate returned silently, so owners never saw an actionable authorization prompt.

This PR makes the foreign-bot gate use the same grant request card mechanism before returning, while preserving the gate itself.

User / Developer Impact

• Owners get a visible, clickable authorization path when an external bot tries to hand work to this bot without prior grant.
• Multi-bot collaboration becomes easier to diagnose: an unauthorized handoff no longer looks like a trigger failure.
• Teams that prefer strict silence for unknown senders can disable the behavior per bot from Dashboard or by setting autoGrantRequestCards: false in bots.json.

Validation

• corepack pnpm vitest run test/event-dispatcher.test.ts test/bot-registry-grant.test.ts test/dashboard-bot-payload.test.ts
  • 145 tests passed.
• PATH=/tmp/botmux-corepack-bin:$PATH pnpm build
  • TypeScript compile and dashboard bundle passed.
• git diff --check
  • Passed.

Notes

The first push to upstream deepcoldy/botmux was denied for this SSH identity, so the branch is pushed from the nil-err/botmux fork and this PR targets deepcoldy/botmux:master.