Admin UI: multi-step webhook blocker + corrected unsupported copy

[kevin9foong]

Parent

PRD #9972 — MRF V1 backward-compatible webhooks for single-step forms.

What to build

An admin on a multirespondent form sees the truth about webhooks in their settings: available on a single-step form, and explicitly unavailable-with-a-reason on a multi-step one. They are never shown a control that cannot succeed.

Two problems today. The webhook settings section appears for any multirespondent form once enable-mrf-webhooks is on, including multi-step forms whose save the server now rejects. And the message shown when webhooks are unavailable says they are "only available in storage mode", which the flag makes false.

Pinned implementation decisions (Do not deviate)

• Mirror the server predicate exactly — at most one workflow step, meaning no workflow, an empty workflow, or exactly one step. The UI is an affordance; the server's rejection is the guarantee. If they disagree, the server wins and the UI is the bug.
• The unavailable-state copy must be corrected. "Webhooks are only available in storage mode" becomes false the moment the flag is flipped for any multirespondent form. Replace it with copy that names the actual reason for each case: response mode, or multi-step workflow.
• Distinguish the two unavailable reasons. A storage-mode-unsupported form and a multi-step multirespondent form are different situations and must not share one message.
• No webhookFormat control, and no disabled placeholder. The field and its backend resolution are wired in Generic V1 content delivery for single-step MRF forms (initial send) #9975 (PIN-17), but deliberately with no admin UI — it is set out-of-band during the pilot. This pin is unchanged in effect; only its reason has changed.
• The multi-step unavailable state is shown for every multi-step multirespondent form. There is no webhookFormat exemption to mirror — the server has none either (Reject non-plumber webhook URL together with multi-step workflow #9976), because 'v4' is not a settable value for a non-plumber consumer. Do not read the field. When generic-v4 ships, both the server predicate and this screen gain a format term together.
• Behind enable-mrf-webhooks, like the rest of the multirespondent webhook surface.
• Plumber URLs are exempt from the multi-step restriction server-side, but the admin UI has no notion of consumer type and must not try to infer one from the URL as the admin types. Show the multi-step unavailable state for multi-step forms; a plumber-URL multi-step form is configured out-of-band and is not an admin-UI flow.

Acceptance criteria

• A multirespondent form with no workflow, or exactly one step, shows the webhook settings section normally when the flag is on.
• A multirespondent form with two or more workflow steps shows an unavailable state naming the multi-step reason, with no editable URL field.
• A storage-mode form is unaffected.
• An email-mode form shows the response-mode unavailable state with corrected copy.
• No form-format selector appears anywhere.
• With the flag off, multirespondent forms show the unavailable state as today.

Test gates

Permanent gates (keep in the suite long-term)

• Render table over response mode × workflow step count × flag state, asserting which state renders and that the URL field is absent in every unavailable state.
• The two unavailable reasons render distinct copy.

Steering gates (removed once verified)

• [STEERING:T9] copy no longer claims storage-mode-only — a check that the superseded string is gone. Delete once merged.

Blocked by

• Reject non-plumber webhook URL together with multi-step workflow #9976 — Reject non-plumber webhook URL together with multi-step workflow

[linear-code]

FRM-2602