This pull request migrates and refactors the MCP (Model Context
Protocol) Teams bot example from `@examples/mcp` to
`@examples/mcp-server`, significantly expanding its functionality and
improving its documentation and code structure. The new implementation
provides a robust MCP server that exposes human-in-the-loop tools for
Teams, including notification, question/answer, and approval flows.

**Key changes include:**

### 1. Migration and Renaming
- The example is moved from `@examples/mcp` to `@examples/mcp-server`,
with all related files and documentation updated to reflect the new
name. (`README.md`, `CHANGELOG.md`, `package.json`, directory and file
renames)

### 2. Major Feature Expansion
- Implements a full-featured MCP server for Teams, supporting five
tools: `notify`, `ask`, `getReply`, `requestApproval`, and
`getApproval`. These tools allow agents or clients to interact with real
users via Teams for notifications, Q&A, and approval workflows.

### 4. Removal of Old Implementation
- Deletes the previous minimal MCP bot implementation and its associated
files, including the old `README.md`, `manifest.json`, and TypeScript
entry point, which are replaced with the new, more capable server.

…erride in final message (#553)

Fixes #549 

## Summary
Fixes two bugs in HttpStream:

### Bug 1: streamType overwritten to informative in final message
close() calls .addStreamFinal().withChannelData(this.channelData). Since
this.channelData contains streamType: informative from typing updates,
it overwrites the final value.

### Bug 2: Race condition in close()
The while loop checks queue.length and this.id but not this._flushing.
If flush() drained the queue but is still awaiting pushStreamChunk()
calls, close() proceeds immediately.

### Fixes
1. Swap .withChannelData() and .addStreamFinal() order
2. Add || this._flushing to the while condition"

---------

Co-authored-by: Copilot <[email protected]>

equivalent to these 2 python PRs:
microsoft/teams.py#340 (not all applicable bc TS
doesnt have defined inbound/outbound interfaces)
microsoft/teams.py#336

This pull request adds deprecation warnings to several activity-related
interfaces and types to clarify that certain properties and activities
are no longer recognized or returned by the service backend. This
improves the clarity of the API and helps developers avoid using
obsolete features. Verified with APX repo and manual testing.

**Deprecation of properties and activities:**
* Marked the `relatesTo` property as deprecated in the base `IActivity`
interface, the `Activity` class, and in all derived activity interfaces
where it appears, indicating it is no longer returned by the backend.
* Added `@deprecated` annotations to the `withRelatesTo` method in the
`Activity` class for consistency.

**Deprecation of activity types not recognized by the backend:**
* Marked the `IHandoffActivity` and `ITraceActivity` interfaces as
deprecated
* Marked the `IEndOfConversationActivity` interface and
`EndOfConversationCode` type as deprecated

---------

Co-authored-by: lilydu <[email protected]>
Co-authored-by: Copilot <[email protected]>

## Summary

Adds Azure AD v1 issuer support to inbound Entra token validation in
`@microsoft/teams.apps`.

Specifically, tenant-based issuer validation now accepts both:
- `https://login.microsoftonline.com/{tenantId}/...`
- `https://sts.windows.net/{tenantId}/`

## Motivation

Some valid Microsoft Entra tokens are issued with the Azure AD v1 issuer
format (`sts.windows.net`) instead of the v2-style
`login.microsoftonline.com/.../v2.0` issuer.

Related external issue:
- openclaw/openclaw#64270

This PR keeps the change narrowly scoped to issuer validation only.

## Changes

- Extend tenant-based issuer validation in `JwtValidator` to also
accept:
  - `https://sts.windows.net/{tenantId}/`
- Add tests covering v1 issuer acceptance for:
  - single-tenant apps
  - multi-tenant apps

## Tests

Added/updated tests for:
- v1 `sts.windows.net` issuer acceptance
- existing tenant-based issuer validation behavior
- end-to-end validation of Microsoft Entra v1 and v2 access tokens,
modeled on the published sample tokens at
https://learn.microsoft.com/en-us/entra/identity-platform/access-tokens
(same `iss`, `aud`, `tid`, `azp`/`appid`, `scp`, `ver` shape) — both
pass through the full `JwtValidator.validateAccessToken` pipeline
(signature + expiry + audience + issuer + scope)

# Conflicts:
#	version.json

Merges main into release and sets version to 2.0.10.

## Commits since last release

- 7147cd8 fix(apps): support AAD v1 issuers in token validation (#556)
- eb8037e address model gaps (#525)
- ac21af6 fix(http-stream): resolve race condition in close() and
streamType override in final message (#553)
- 6b0da8a MCP Server Example on MCP SDK (#534)
- a749172 chore: bump version to 2.0.10-preview (#555)

## Problem

The release pipeline fails on `npm ci` with errors like:

```
npm error Missing: [email protected] from lock file
npm error Missing: @esbuild/[email protected] from lock file
...
```

## Root cause

The pipeline's `NodeTool@0` task uses `versionSpec: '24.x'`, which
provisions Node 24 + **npm 11**. However:

- This repo pins `"packageManager": "[email protected]"` in `package.json`.
- npm 10 only records platform-specific optional dependencies for the
**current** platform when generating `package-lock.json` (so a lockfile
generated on macOS only contains Mac binaries for `@esbuild/*` and
`turbo-*`).
- npm 11 requires **all** platform binaries to be present in the
lockfile and treats missing ones as out-of-sync, failing `npm ci`.

Lockfile is valid under npm 10 — `npm ci` succeeds locally. The mismatch
is purely between the pipeline's npm and the project's pinned npm.

## Fix

Pin the pipeline to Node 22 (LTS), which ships with npm 10, matching the
`packageManager` field and every developer's local environment.

## Alternative considered

Bumping the project to npm 11 (update `packageManager`, regenerate
lockfile under npm 11, force every dev to upgrade). Rejected as larger
blast radius for an unblock-the-release fix.

## Follow-up

This same change needs to be cherry-picked to `release` to unblock the
2.0.10 publish.

Cherry-pick of #559 onto `release` to unblock the 2.0.10 publish
pipeline.

## Why

The publish pipeline fails on `npm ci` on Windows agents because Node 24
ships npm 11, which is stricter than the npm 10 pinned in
`packageManager`. See #559 for full root-cause analysis.

## Change

Pins the `NodeTool@0` task in `.azdo/publish.yml` from `24.x` to `22.x`
(npm 10). One-line fix, no lockfile or dependency changes.

## After merge

Re-trigger the [release
pipeline](https://dev.azure.com/DomoreexpGithub/Github_Pipelines/_build?definitionId=52&_a=summary)
on `release` with **Public** publish type to ship 2.0.10.