docs(teams): propose delivery and trust decisions

[NeoHsu]

Stacked PR: base branch main. Review only this branch's single commit relative to that base.

What problem does this solve?

Define the durable delivery, trust, route, acknowledgement, mutation, reaction, and typed-scope decisions that the implementation stack must satisfy.

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

Review Contract

Goal

Define the durable delivery, trust, route, acknowledgement, mutation, reaction, and typed-scope decisions that the implementation stack must satisfy.

Non-goals

This PR changes no runtime, configuration, deployment manifest, tenant state, or live-validation status.

Accepted Residual Risks

The ADRs remain Proposed until maintainers accept them. Microsoft preview APIs and tenant-specific presentation remain outside the durable decision record and are tracked separately.

Acceptance Criteria

Each ADR has Status, Date, Author, and Related metadata; links resolve; security and failure semantics are testable; no implementation chronology, Review Contract, or live-tenant evidence is embedded.

Follow-ups

Implement the decisions in the following stacked PRs and publish mutable validation evidence only in the final guides PR.

At a Glance

N/A — this PR changes documentation only; it introduces no runtime flow.

Prior Art & Industry Research

Not applicable — this is a documentation-only decision or guidance slice. The ADRs and guides cite the authoritative Microsoft and repository sources used for their claims.

Proposed Solution

• Add six Proposed ADRs for capability negotiation, ephemeral ingress trust, real send acknowledgement, owned mutations, reaction preview, and typed Teams scope.
• Keep durable security and delivery decisions separate from mutable tenant evidence.
• Preserve the existing Custom Gateway ADR as the historical architecture authority.

Why this approach?

Separating durable ADRs from mutable guides and evidence keeps architecture review stable while allowing operational status to evolve.

Alternatives Considered

Embed implementation chronology and tenant evidence in ADRs (rejected: it becomes stale) or publish no routing guide (rejected: operators cannot discover the supported path).

Validation

• git diff --check
• Relative Markdown link and form audit
• ADR metadata and mutable-section guards