#16622: fix(mattermost): record pending history for messages dropped by groupAllowFrom

Fixes #16621 ## What When a message in a channel is dropped because the sender is not in `groupAllowFrom` (e.g. another agent's bot reply), the message is now saved as pending history via `recordPendingHistoryEntryIfEnabled()`. ## Why In multi-agent setups where several bots share a channel, each bot only has the human user in its `groupAllowFrom`. Other bots' replies get dropped — and previously, that meant the conversation context was lost. When an agent was later @mentioned, it couldn't see what other agents had said. ## How Before the early `return` in the `groupAllowFrom` check, we now: 1. Resolve the route/session key (using the same logic as the main flow) 2. Call `recordPendingHistoryEntryIfEnabled()` with the message content This uses the existing pending history infrastructure — no new config or breaking changes. The existing `historyLimit` setting controls the buffer size. ## Testing Tested manually with two agents (Ada + Erik) in a shared Mattermost channel. Before: Erik couldn't see Ada's replies. After: Erik sees full conversation context when @mentioned. <!-- greptile_comment --> <h3>Greptile Summary</h3> This PR adds pending history recording for messages dropped by the `groupAllowFrom` check in the Mattermost monitor. Previously, when a sender was not in `groupAllowFrom` (e.g., another bot in a multi-agent channel), the message was silently discarded. Now, the message is saved as pending history before the early return, so that when the agent is later `@mentioned`, it has context about what other agents said. - Resolves route and session keys using the same logic as the main message-handling flow, then calls `recordPendingHistoryEntryIfEnabled()` before the early return in the `groupAllowFrom` gate - The route resolution correctly uses `channelId` as the peer ID (consistent with the main flow for non-direct messages) - No new configuration, dependencies, or breaking changes — this leverages the existing pending history infrastructure and `historyLimit` setting <h3>Confidence Score: 5/5</h3> - This PR is safe to merge — it adds a well-scoped side effect (recording pending history) before an existing early return, using established patterns from the same file. - The change is small, self-contained, and mirrors existing patterns already used later in the same function. The route/session/history logic is consistent with the main flow. The guard conditions prevent recording empty or invalid entries. No new external dependencies or configuration surface. The existing historyLimit setting controls buffer size. - No files require special attention. _{Last reviewed commit: 86b7516} <!-- greptile_other_comments_section --> _{(3/5) Reply to the agent's comments like "Can you suggest a fix for this @greptileai?" or ask follow-up questions!} <!-- /greptile_comment -->