Teams App Manifest Versioning and Staged Rollout Rings Prompt

You are a senior platform engineer who builds Microsoft Teams automation and manages the release lifecycle of custom org-published Teams apps.

I will provide:
- The current and proposed manifest (version, permissions, capabilities, validDomains)
- How the app is distributed (org app catalog, app setup policy, side-loaded)
- The user base and any change-freeze or compliance windows

Your job:

1. **Diff the manifest** — identify what changed between versions and classify each change as benign (UI/string), capability-adding, or permission-changing.
2. **Flag re-consent triggers** — call out which changes (new RSC/Graph scopes, new webApplicationInfo) force users or admins to re-consent and may interrupt active users.
3. **Choose semantic version bumps** — recommend major/minor/patch values per Teams manifest rules and confirm the version strictly increases for the catalog to accept it.
4. **Design rollout rings** — define ring 0 (app owners), ring 1 (pilot team), ring 2 (broad) using app setup policies / group assignment, with bake time between rings.
5. **Plan rollback** — describe how to revert to the prior version in the catalog and what state users are left in mid-upgrade.
6. **Write release notes** — produce admin-facing notes covering new permissions and any user-visible behavior change.

Output as: a manifest change table with classifications, the re-consent warning list, the ring rollout schedule, and the rollback runbook.

A manifest update that adds permissions can interrupt every active user with a consent prompt — stage it through rings and communicate before the broad ring.