Bug: Bot posts turn-limit warning in channels it is not allowed in

[themaxagent]

Description

The WarnAndStop path in the bot turn limiter (discord.rs ~L295-310) uses parent_id to
check whether a bot is allowed to post a warning, but does not check thread_metadata
to distinguish threads from category children. This is the same class of bug fixed by
detect_thread() (PRs #506/#518/#519), but the fix was never applied to the WarnAndStop
code path.

When a text channel's parent_id (its Discord category) happens to match an entry in
another bot's allowed_channels, allowed_here is incorrectly set to true, causing that
bot to post a turn-limit warning in a channel it should not have access to.

Steps to Reproduce

1. Configure two agents — e.g. Kiro with allowedChannels: [A] and Gemini with
   allowedChannels: [B], where channel A is a text channel under a Discord category
   whose ID matches one of Gemini's allowed channels (or vice versa).
2. Set up a Kiro cronjob that fires periodically in channel A (a non-thread channel
   message).
3. Since cronjob messages are bot messages with no human resets, the bot turn counter
   accumulates across firings.
4. Once the counter hits soft_limit (default 20), Gemini's WarnAndStop fires.
5. The allowed_here check resolves parent_id (the category ID) against Gemini's
   allowed_channels — matches — and Gemini posts a warning in channel A where it is not
   supposed to operate.

Expected Behavior

Gemini should NOT post the turn-limit warning in channel A. The WarnAndStop path
should use thread_metadata (like detect_thread() does) to distinguish actual
threads from category children. Only when thread_metadata is present should
parent_id be used for the allowed-channel lookup:

if gc.thread_metadata.is_some() && gc.parent_id.is_some_and(|pid| {
    self.allowed_channels.contains(&pid.get())
}) {
    allowed_here = true;
}

Environment

• OpenAB v0.8.2-beta.3
• discord.rs WarnAndStop block (~L295-310)

Screenshots / Logs

discord discussion: https://discord.com/channels/1491295327620169908/1496961096182006023/1498772341394772130

[CHC-Agent]

Issue at a Glance

WarnAndStop triggers on #kiro-channel (a regular channel, not a thread)
       │
       ▼
  Gemini checks: am I allowed here?
       │
       ▼
  Step 1: channel_id ∈ allowed_channels? → NO
       │
       ▼
  Step 2: query Discord API → parent_id = Category ID
          parent_id ∈ allowed_channels? → YES ❌
       │
       ▼
  parent_id is a Category, not a parent thread channel.
  But if allowed_channels contains that Category ID
  (e.g. user copied the wrong ID from Discord UI),
  the check passes incorrectly.

  The fix: only run Step 2 when thread_metadata is present
  (i.e. the channel is actually a Thread).

Hi @themaxagent,

Confirmed — the WarnAndStop path at discord.rs ~L295-310 queries parent_id and checks it against allowed_channels without first verifying thread_metadata.is_some(). For regular (non-thread) channels, parent_id points to the Discord Category, not a parent channel. If allowed_channels happens to contain that Category ID, the check incorrectly passes.

The detect_thread() function (L970) already guards against this by checking thread_metadata first, but the WarnAndStop code path was missed when PRs #506 / #518 / #519 landed.

Related:

• PR refactor(discord): unify thread detection into single to_channel() call #506 by @AkashiSN — MERGED (refactor thread detection into to_channel())
• PR fix(discord): use ChannelType to detect threads instead of parent_id #518 by @AkashiSN — MERGED (use ChannelType for thread detection)
• PR fix(discord): use thread_metadata instead of parent_id for thread detection #519 by @AkashiSN — MERGED (use thread_metadata for thread detection)

The fix is small — add a gc.thread_metadata.is_some() guard before the parent_id lookup in the WarnAndStop block. PR welcome.