fix(webhook): disable async delivery for single-shot HTTP ingress

[Bartok9]

Summary

Closes #69145

Webhook (and MS Graph webhook) one-shot sessions still strand background delegate_task results: the parent turn ends, the session is marked ended, and the #55578 fail-closed path drops async completion injection. #66617 fixed the same class of bug for hermes -z and cron via declare_stateless_channel() / async_delivery=False; the gateway path already propagates each adapter's supports_async_delivery flag in _set_session_env, but webhook left the default True.

Motivation / Root cause

• Stateless HTTP ingress is one inbound → one response (same contract as API server).
• Top-level delegation is often forced background=True.
• After the parent finish_reason=stop, completions cannot safely re-enter an ended session.

Fix

Set supports_async_delivery = False on:

• gateway/platforms/webhook.py — WebhookAdapter
• gateway/platforms/msgraph_webhook.py — MSGraphWebhookAdapter

APIServerAdapter already does this. Tools that consult async_delivery_supported() then fall back to synchronous inline delegation (existing #53027 / #63142 / #66617 path).

Tests

• Extended tests/gateway/test_async_delivery_capability.py::TestAdapterCapabilityFlag::test_api_server_false to assert webhook + msgraph flags.

Verification

pytest tests/gateway/test_async_delivery_capability.py -q

15 passed.

[alt-glitch]

This was generated by AI during triage.

Related to #69159 and #69145. Both open PRs set WebhookAdapter to disable async delivery for finite sessions; this patch also applies the capability flag to MSGraphWebhookAdapter. Maintainers can choose whether to consolidate the overlapping webhook hunk.

[Bartok9]

Thanks @alt-glitch — good catch on the overlap. This PR's distinct value is extending the capability flag to MSGraphWebhookAdapter, which #69159 and #69145 don't touch. Happy to defer to maintainers on consolidation: if you'd prefer to land the shared webhook hunk in one of those, I can rebase this down to just the MSGraph-adapter delta so there's no duplicated change. Just say the word.

[teknium1]

Thanks for tracing the generic webhook lifecycle. The WebhookAdapter portion addresses a verified current-main gap: it inherits supports_async_delivery=True while its on_processing_complete closes each delivery session (gateway/platforms/webhook.py:936-1016), and GatewayRunner._set_session_env propagates that capability to delegate_task (gateway/run.py:18013-18029).

Problems

• MSGraphWebhookAdapter is not shown to have the same lifecycle. It uses a stable subscriptionId chat id (gateway/platforms/msgraph_webhook.py:391-405) and schedules notifications through a pipeline or handle_message (gateway/platforms/msgraph_webhook.py:437-453); unlike generic webhook, it has no on_processing_complete session-close override. Marking it non-delivering would force synchronous delegation without a demonstrated stranded-completion path.
• The added test checks only class attributes. It does not verify the gateway binding that makes the flag effective.

Suggested changes

• Scope this PR to WebhookAdapter; investigate MS Graph separately if a concrete ended-session reproduction exists.
• Add a GatewayRunner._set_session_env regression test for webhook binding, with a supported-delivery control.

Automated hermes-sweeper review.

[Bartok9]

Thanks @teknium1 — applied both suggestions:

• Scoped to WebhookAdapter. Dropped the MSGraphWebhookAdapter flag; you're right that it has no demonstrated ended-session path — stable subscriptionId chat id and no on_processing_complete session-close override, so marking it non-delivering would force sync delegation without a real stranded-completion repro. Will investigate MS Graph separately only if a concrete reproduction shows up.
• Real gateway-binding test. Replaced the class-attribute-only check with a GatewayRunner._set_session_env regression test that verifies the webhook inbound actually binds async_delivery=False through the live adapter lookup, plus a delivering-platform (telegram) control that binds True on the same path — so the webhook False is a real signal, not a blanket off.

Green locally (pytest tests/gateway/test_async_delivery_capability.py → 17 passed).