feat(teams): add processing message lifecycle

[NeoHsu]

Important

Stacked draft: logical base stack/teams-05-typed-scope-routing is PR #1497. GitHub requires an upstream PR base to exist in openabdev/openab, so this draft temporarily targets main and may show preceding stack layers. Do not merge it until #1497 is merged and this branch is rebased onto current main; then review only its single incremental commit.

What problem does this solve?

Give opted-in Teams users a bounded processing indicator without optimistic writes or duplicate visible messages.

Discord Discussion URL: https://discord.com/channels/1491295327620169908/1491365158868619404/1531339032527765655
Microsoft Teams roadmap discussion.

Review Contract

Goal

Give opted-in Teams users a bounded processing indicator without optimistic writes or duplicate visible messages.

Non-goals

Progressive answer streaming, reactions-as-processing, automatic ambiguous cleanup retry, and default enablement are excluded.

Accepted Residual Risks

An Unknown edit or delete can leave a stale indicator; preserving uncertain platform state is safer than issuing another write.

Acceptance Criteria

The feature is default off and requires all negotiated primitives; it uses one real activity ID; terminal status precedes cleanup; failed or ambiguous operations never trigger a duplicate fresh send.

Follow-ups

Add progressive answer replacement separately and collect remaining failure-cleanup UI evidence.

At a Glance

Authenticated Teams activity / operator target
                    │
                    ▼
            [this PR’s bounded layer]
                    │
                    ▼
          explicit outcome or fail-closed stop

Prior Art & Industry Research

OpenClaw: its Microsoft Teams extension separates access checks, Bot Framework route context, and outbound operations. For this slice the relevant comparison is status lifecycle presentation before a final response.

Hermes Agent: its Teams platform adapter keeps Teams-specific transport and message shaping behind a platform adapter. It does not provide OpenAB’s negotiated Core/Gateway outcome contract, so this PR keeps the useful adapter boundary but adds explicit fail-closed semantics.

Proposed Solution

• Add an explicit Teams processing-message lifecycle.
• Require every negotiated send/edit/delete primitive before enabling it.
• Reuse one real owned activity and clean it up only after a terminal update.

Why this approach?

Reusing one acknowledged activity avoids duplicate status messages and preserves uncertainty instead of retrying blindly.

Alternatives Considered

Use an unacknowledged placeholder or reaction-only status (rejected: no owned cleanup contract) or enable by default (rejected: behavior change).

Validation

• cargo check -p openab-core
• cargo check -p openab-gateway --features teams