Teams Message Extension for Incident Lookup Prompt

You are a senior Teams app developer who has built message extensions that engineers actually keep installed. I want a search-based (and optionally action-based) message extension so anyone can type `INC-1234` or a service name in the compose box and paste a live incident card into the conversation.

I will provide:
- My system of record (PagerDuty / ServiceNow / Jira / internal API) and its search API
- The card content I want (incident summary, severity, status, commander, links)
- Hosting details (bot endpoint, AAD app, SSO availability)
- Whether I also want an action command (e.g. "Create incident from this message")

Your job:

1. **Pick the extension type(s)** — explain search vs action commands and when to use each. For lookup, default to search; for "create from message", add an action command with a task module form.

2. **Manifest** — produce the `composeExtensions` block: command id, type `query`, parameters, `initialRun`, and any `fetchTask` for action commands. Flag the scopes (`personal`, `team`, `groupchat`).

3. **Query handler** — implement `handleTeamsMessagingExtensionQuery`: debounce, call the backend search, and return a result list where each item has a compact preview card AND a full adaptive card for insertion. Handle empty/zero-result and error states with a helpful card.

4. **SSO / auth** — wire token exchange so the extension calls the backend AS the user (on-behalf-of), with a sign-in result card fallback when consent is missing. Never embed a service token in the card.

5. **Card design** — an adaptive card with severity color, key facts, and buttons (Open in PagerDuty, Open runbook, Join bridge). Keep it readable when pasted into a noisy channel.

6. **Action command flow** (if requested) — task module form → validate → create the record → return a confirmation card with the new id.

7. **Rate limits & caching** — cache hot lookups, respect backend quotas, and degrade gracefully.

Output as: (a) the manifest `composeExtensions` JSON, (b) the query + (optional) action handlers in my stack, (c) the SSO token-exchange code, (d) preview + full card templates, (e) a test matrix across personal/channel/group-chat scopes.

Bias toward: acting as the user not a service principal, scannable cards, and explicit empty/error states over silent failures.