spec: extend three-shape submitted-envelope pattern to other sync_* operations

[bokelley]

Raised during PR #2434 review (ad-tech-protocol-expert #6, adtech-product-expert #2, dx-expert): if `sync_creatives` gets a top-level `SyncCreativesSubmitted` envelope for operation-level async, we should audit whether the sibling batch mutations warrant the same shape:

• `sync_accounts` — already has per-item `action` + `status`; question is whether operation-level async (governance review gating the whole sync) is a real scenario.
• `sync_audiences` — audience matching is classically async (capabilities already declares `audience_targeting.matching_latency_hours`); batch ingestion that can't return per-item results synchronously seems plausible.
• `sync_event_sources` — same question.
• `activate_signal` — currently two-shape, explicitly atomic. Flag for 4.0 if async signal activation becomes real.

Decision needed: either (a) extend the envelope pattern across sync_* to maintain symmetry, or (b) confirm and document why only sync_creatives warrants it, so the asymmetry is deliberate rather than an oversight.

Preferred path: do a short design pass with SDK implementers before extending, to avoid locking in a pattern in batches where no seller actually needs operation-level async.

Follow-up to #2428 / PR #2434.

[bokelley]

Cross-linking a related client-side fix that changes the shape of this decision.

adcontextprotocol/adcp-client#646 reported that ProtocolResponseParser.getStatus() misclassified any MCP response whose structuredContent.status matched an ADCP task-status literal — four of those (completed/canceled/failed/rejected) collide with domain status enums like MediaBuyStatus and CreativeStatus. The collision hit cancel_media_buy first, but sync_creatives has exactly the same shape by construction: a flat envelope with top-level status: "completed" alongside a domain payload (creatives[] + summary). Any compliant SyncCreativesSuccess response was being routed through the terminal-failure branch.

adcontextprotocol/adcp-client#649 fixes it at the parser layer with an envelope-shape check: exclusive task-lifecycle literals (submitted/working/input-required/auth-required) are trusted unconditionally; shared literals are only treated as task status when structuredContent has no keys outside the ProtocolEnvelope allowlist. Otherwise we fall through and Zod validators parse the domain payload.

Implication for this issue: the three-shape pattern is no longer blocked by a client-side soundness problem. The invariant the parser fix relies on — "shared-literal status + domain payload keys ⇒ domain envelope" — is exactly the structural property #2435 would codify at the spec layer. That reframes the decision:

• Pull forward: only if we believe sellers will produce ambiguous envelopes in the field. The client fix proves the invariant holds in practice; making it structural just makes it harder for a future seller to violate. Real value, but hardening rather than unblocking.
• Hold for 3.1.0 design pass: the client-side generalization catches every current and future sync_* operation with a status collision, works against non-compliant / legacy servers, and needs no seller migration. The spec question can focus on the real design trade-off — "do sync_accounts / sync_audiences / sync_event_sources actually need operation-level async?" — without the collision bug pressing on the timeline.

Recommendation: keep at 3.1.0. During the design pass, my current bet is extending to sync_audiences (matching is classically async; audience_targeting.matching_latency_hours already declares it) and leaving sync_accounts alone (per-item action + status already covers the realistic cases). sync_event_sources depends on whether seller-side validation of stream endpoints is a real latency source — worth asking implementers.

Flagging so this doesn't get treated as a protocol-soundness blocker; it isn't one anymore.