Leaving the same note on the other PRs in the stack for visibility.

Could you retarget this PR's base branch so diffs are incremental instead of cumulative? Full detail in #21408 (comment) but tl;dr:

• feat(msgraph): add webhook listener platform #21409 → base pr/msgraph-auth-client
• feat(teams-pipeline): add plugin runtime and operator cli #21410 → base pr/msgraph-webhook-listener
• feat(teams): add pipeline outbound delivery via existing adapter #21411 → base pr/teams-pipeline-plugin-runtime
• docs(teams): split meetings setup from operator runbook #21412 → base pr/teams-outbound-delivery

gh pr edit <N> --base <branch> does it in place — no close/reopen, comments and CI preserved. GitHub auto-retargets up the stack as each one merges.

Planning to review bottom-up from #21408. Thanks.

Merged via PR #22007. Your commit feat(teams-pipeline): add plugin runtime and operator cli landed on main with your authorship preserved via rebase-merge — see commit 07bbd9333.

One follow-up added on top during salvage:

fix(teams-pipeline): drop-scheduler fallback + test wiring for enablement gate —

1. Drop-scheduler on runtime build failure. Previously when build_pipeline_runtime() raised (missing Graph env, bad store path, etc.), bind_gateway_runtime left the msgraph_webhook adapter with no scheduler. Graph notifications would then fall through to the adapter's default handle_message, which manufactures a raw-JSON user message on every Graph retry. Now a no-op drop-scheduler is installed so notifications ack cleanly (202), the failure is logged once, and no synthetic messages get generated. The adapter stays bindable later once config is fixed.

2. Test wiring: two of the happy-path runner-wiring tests monkeypatched bind_gateway_runtime but not _load_gateway_config, so in the hermetic test env the real config read ran, saw no enabled plugins, and short-circuited the bind call. Added the config monkeypatch. Also renamed test_bind_gateway_runtime_leaves_scheduler_unchanged_on_failure → test_bind_gateway_runtime_installs_drop_scheduler_on_failure and updated its assertion — it contradicted your own test_bind_gateway_runtime_drops_notifications_when_unavailable; both tests now consistently verify the drop-scheduler is installed.

Stale-base note: the branch was 142 commits behind main and carried spurious reverts of three unrelated recent main commits on gateway/run.py (_resolve_home_env_var plugin-registry lookup, informative bootstrap error reporting, fallback-provider model logging). Those reverts were discarded during salvage; only the genuine teams_pipeline additions landed. None of your intended work was lost.

Remaining PRs in the stack (#21411 outbound delivery, #21412 full setup docs + runbook + SKILL.md) are next. Thanks!