bug(discord): thread owner stops answering un-mentioned messages in multibot-mentions threads (docs say it should) #1566

Summary

In multibot-mentions mode, the bot that owns a thread stops answering un-mentioned messages as soon as any other bot posts there. docs/discord.md disagrees with itself on what should happen:

• The comparison table under allow_user_messages (Multi-bot thread, no @mention → ❌) matches the code.
• The allowed_role_ids section ("Follow-up in the thread without @mention → Only the thread owner responds") describes the behaviour we expected.

The code (crates/openab-core/src/discord.rs, AllowUsers::MultibotMentions, ~L801-822 on main at 8b6bf29) treats the owner like any other bot: bot_owns_thread sets involved = true, but other_bot still returns early.

Why it matters

The common multi-bot pattern is: chat with bot A in its own thread, then @mention bot B once for a second opinion. After B replies, A needs an @mention on every message for the rest of the thread, because the multi-bot flag is persisted and never clears. The owner loses the natural, mention-free conversation that multibot-mentions is meant to keep.

Proposed fix (opt-in, default = today's behaviour)

A [discord] setting thread_owner_involved (bool, default false). When true, for an un-mentioned message in a thread, these rules apply before the normal gate:

1. If the message @mentions a different bot (a user mention, or that bot's managed role), every bot ignores it, because the human is addressing that bot.
2. Otherwise, if this bot owns the thread (owner_id), it answers, even if other bots have posted.
3. Otherwise the normal multibot-mentions gate applies, so a non-owner bot still needs a mention.

This changes only which bot answers a message that has already been admitted. allowed_users, allow_bot_messages and trusted_bot_ids are untouched.

We have run this (plus some unrelated additions) on six bot families in production since 2026-10-21, with live tests of: the owner keeps answering after a guest bot posts; a message addressed to the guest is ignored by the owner; a guest still needs a mention. The rule itself is a small pure function plus about ten lines in the handler, with unit tests.

Happy to open a PR with just this rule (setting, gate change, tests, and a docs fix for the two contradicting sections) if you'd like it. Or, if you'd rather keep the current behaviour, the allowed_role_ids table row should probably be corrected instead.