#13089: fix(msteams): alias team config under channel conversation IDs for Agents SDK (#9873)

## Problem The Microsoft Agents SDK (which replaced Bot Framework) no longer populates `activity.channelData.team.name` or `activity.channelData.channel.name`. Only `.id` fields are provided: ```json { "teamId": "19:rcybyx4n54wO1UF__3XVOyW8YwwPLibpjTNmQpCRUSQ1@thread.tacv2", "teamName": null, "channelName": null, "teamObj": {"id": "19:...@thread.tacv2"}, "channelObj": {"id": "19:...@thread.tacv2"} } ``` At startup, the channel resolution maps user-friendly config keys (e.g. `"Automation"`) to **Graph API group IDs** (e.g. `fa101332-cf00-431b-...`). But the Agents SDK sends the **channel conversation thread ID** (e.g. `19:abc...@thread.tacv2`) as `activity.channelData.team.id`. This ID mismatch causes the allowlist matcher to never find a team match, silently dropping **all** channel messages when `groupPolicy: "allowlist"` is set. DMs are unaffected. ## Root Cause 1. Monitor startup resolves `"Automation"` → Graph group ID `fa101332-...` and re-keys `teams:` config 2. Incoming message has `teamId = "19:rcybyx4n54wO1UF__...@thread.tacv2"` (conversation thread ID) 3. `buildChannelKeyCandidates(teamId, teamName)` produces only the thread ID (teamName is null) 4. `resolveChannelEntryMatchWithFallback` tries to match thread ID against Graph group ID keys → no match 5. `channelGate.allowed = false` → message dropped ## Fix After resolving each channel during startup, also register the team config under the channel's conversation ID. This ensures the allowlist matcher can find the team config regardless of which ID format the SDK provides. **Change: `extensions/msteams/src/monitor.ts`** — 9 lines added in the resolution loop **Test: `extensions/msteams/src/policy.test.ts`** — New test case for null teamName/channelName with ID-based matching ## Debugging Evidence Captured from a live 2026.2.9 deployment: ``` msteams channels resolved: Automation/General→fa101332-cf00-.../19:rcybyx4n54wO1UF__...@thread.tacv2 ``` Activity data (teamName/channelName both null): ```json {"teamId":"19:rcybyx4n54wO1UF__...@thread.tacv2","teamName":null,"channelName":null} ``` Log confirming the drop: ``` dropping group message (not in team/channel allowlist) ``` ## Workaround (for users on current release) Set `groupPolicy: "open"` in msteams config. The `teams:` block with `requireMention: true` still gates when the bot responds. Closes #9873 <!-- greptile_comment --> <h2>Greptile Overview</h2> <h3>Greptile Summary</h3> This PR updates the Microsoft Teams extension’s startup allowlist resolution to handle an ID mismatch introduced by the Microsoft Agents SDK. During channel resolution in `extensions/msteams/src/monitor.ts`, the resolved team config (keyed by the Graph group ID) is also aliased under the channel conversation thread ID when they differ, so inbound events that provide only `activity.channelData.team.id` as a thread ID can still match allowlisted teams/channels. It also adds a regression test in `extensions/msteams/src/policy.test.ts` covering the Agents SDK case where `teamName`/`channelName` are absent and matching must succeed based on ID keys alone. <h3>Confidence Score: 4/5</h3> - This PR is likely safe to merge and narrowly addresses the reported ID mismatch in allowlist matching. - Changes are small and localized to config resolution/aliasing, and the added test exercises the Agents SDK null-name scenario. I could not run tests in this environment (no node/pnpm available), so the score is slightly reduced due to lack of execution verification. - extensions/msteams/src/monitor.ts <!-- greptile_other_comments_section --> _{(2/5) Greptile learns from your feedback when you react with thumbs up/down!} <!-- /greptile_comment -->