[Feature] Support Bot Framework / Webhook-based Teams connector instead of OBO user impersonation

The SRE wrote this up, so....
# GitHub Issue for microsoft/sre-agent

**Title:** [Feature Request]: Support Bot Framework / Webhook-based Teams connector instead of OBO user impersonation

**Labels:** `enhancement`

---

## Issue Body (copy below this line):

### Is your feature request related to a problem?

Yes. The current Teams connector requires a human administrator to sign in via OAuth, and all messages the agent sends to Teams are posted **as that human user**. This creates several problems:

1. **Identity misrepresentation** — Team members see messages from a person (e.g., "Chad Carlton") when the message is actually from the SRE Agent. This is confusing and undermines trust in the notifications.
2. **Single point of failure** — If the authenticated user's credentials rotate, their account is disabled, or they leave the organization, the Teams connector breaks silently.
3. **Accountability gap** — Audit logs attribute agent-generated messages to a human, making it impossible to distinguish human-initiated vs. agent-initiated communications.
4. **Security concern** — The agent operates under a human's delegated identity with broader permissions than necessary for posting to a single channel.

The agent already has its own managed identity (UAMI) for Azure resource operations. It should be able to use a service identity for Teams notifications too.

### Describe the solution you'd like

Support one or more of these alternatives to OBO-based Teams messaging:

#### Option A: Bot Framework Registration
Allow the agent's Teams connector to authenticate as a **registered Teams Bot** rather than impersonating a user.

- The customer registers a Bot in Azure (Bot Channel Registration or Azure AI Bot Service)
- The bot is installed into the target Teams channel/team
- The agent posts messages as the bot identity (e.g., "Cloud Engineering SRE" bot)
- No M365 user license required — Bot Framework supports app-only auth
- Messages are clearly attributed to the bot, not a human
- Microsoft Graph's `ChannelMessage.Send` requires delegated permissions for user messages, but Bots use the Bot Framework REST API (`/v3/conversations/{id}/activities`) which supports app-only auth natively

#### Option B: Power Automate / Logic App Webhook
Allow the agent to post to Teams via an **HTTP webhook** that triggers a Power Automate flow or Logic App, which then posts to the channel.

- Customer creates a Power Automate "When an HTTP request is received" flow → "Post message in a chat or channel"
- Agent connector is configured with the webhook URL
- No OBO needed — the flow runs under its own connection
- Lower setup overhead than Bot Framework
- Messages can be formatted as Adaptive Cards

#### Option C: Managed Identity with Graph API (future)
If/when Microsoft Graph adds **application permission support for `ChannelMessage.Send`** (currently delegated-only), allow the agent's UAMI to post directly via Graph.

- This is blocked today by a Microsoft Graph platform limitation (app-only permissions for channel message posting are restricted to migration scenarios only)
- But it would be the cleanest long-term solution

### Describe alternatives you've considered

- **Current OBO approach** — Works but has all the problems described above. Acceptable as a temporary workaround but not a production-grade solution for autonomous agent notifications.
- **Incoming Webhooks** — Microsoft has deprecated the Office 365 Connector-based incoming webhooks. The replacement "Workflows" approach is essentially Option B above.

### Additional context

- The Outlook/email connector has a viable workaround: customers can create a shared mailbox (no license required), grant `Mail.Send` application permission to the UAMI, and scope it with an Exchange Online Application Access Policy. The agent can then send email as a service identity. A similar "service identity" path for Teams would complete the picture.
- The [SRE Agent docs](https://learn.microsoft.com/en-us/azure/sre-agent/set-up-teams-connector) currently state: *"Your agent sends notifications as the authenticated user"* and *"To change the sending identity, disconnect and reconnect using a different Microsoft account."* This confirms the connector is locked to a single human identity today.
- This affects any organization where the SRE Agent operates autonomously (scheduled tasks, incident response plans) — messages posted at 3 AM from "Chad Carlton" when Chad is asleep erode trust in the notification system.
- Enterprise customers with compliance requirements around identity attribution and audit trails are particularly impacted.

### Environment
- Azure SRE Agent (GA)
- Teams connector via OAuth sign-in
- Agent managed identity: User-Assigned Managed Identity (UAMI)

Start with the current Teams connector behavior and the linked SRE Agent Teams connector documentation, especially its OAuth and authenticated-user statements. Clarify whether Bot Framework or webhook support is in scope, then locate the connector entry point and tests; done means a selected non-human identity path is implemented without breaking existing configuration.

Written by the indexing model from the issue text.