docs(spec): prohibit dual-emission of legacy status fields alongside v3 status

[bokelley]

Closes #2987

Summary

AdCP v3 defines status as the single authoritative task state, but the spec said nothing about agents that continue emitting a legacy task_status (or similar) field alongside it during migration. Scope3 flagged this as an active ambiguity: buyers were assuming v3 status wins on terminal states but had no normative text to cite.

This PR closes the gap with explicit MUST NOT language in three places:

• Migration checklist (docs/reference/migration/index.mdx): adds a "Task status" row so migrating agents have a concrete action item.
• Task lifecycle reference (docs/building/implementation/task-lifecycle.mdx): adds a :::warning callout immediately after the Response Structure section — the primary reference implementors consult from code.
• Protocol envelope schema (static/schemas/source/core/protocol-envelope.json): extends the status property description with the prohibition (sibling keywords on $ref nodes are ignored by draft-07 validators; description is the correct channel for this).

Non-breaking justification

Adds optional normative text and documentation only. No field added, removed, renamed, or made required. No enum values changed. No existing clients need to change code to keep working — the prohibition targets behavior that was already incorrect per intent.

Pre-PR review

Two rounds of review were completed (cap: 2). Both experts approved the substantive conformance language.

• code-reviewer: approved — all three prior blockers confirmed fixed; changeset description updated to remove stale x-adcp-conformance reference.
• ad-tech-protocol-expert: approved content; raised one open question on effort label taxonomy (see below).

Open nit for reviewers: The migration table effort label is Restructure. The protocol expert argues the closest match for a field-removal prohibition is Rename ("find-and-replace semantics"); the code reviewer considers Restructure ("requires code changes") equally valid. Neither Rename nor Restructure is a perfect fit — the table legend has no Remove category. Please pick whichever reads more accurately to you; either is fine. I stopped at the 2-iteration cap rather than introducing a third loop over taxonomy.

Session: https://claude.ai/code/session_01XeNaS3wfWQApdBpDsU5gC7

---

Generated by Claude Code

[github-actions]

IPR Policy Agreement Required

Thank you for your contribution! Before we can accept your pull request, you must agree to our Intellectual Property Rights Policy.

By making a Contribution, you agree that:

• You grant the Foundation a perpetual, irrevocable, worldwide, non-exclusive, royalty-free copyright license to your Contribution
• You grant a patent license under any Necessary Claims
• You represent that you own or have sufficient rights to grant these licenses

To agree, please comment below with the exact phrase:

I have read the IPR Policy

You can read the full IPR Policy here.

---

I have read the IPR Policy

---

_{You can retrigger this bot by commenting recheck in this Pull Request. Posted by the CLA Assistant Lite bot.}

[bokelley]

fix or other changeset entry? spec?

[nastassiafulconis]

Reviewed: docs-only change adding normative prohibition against dual-emission of legacy status fields alongside v3 status. Placement in the envelope's status description (rather than the shared task-status.json enum) is correct given draft-07 $ref sibling-keyword limitations. Changeset and conventions look good.

Non-blocking suggestions:

• Migration row uses Restructure effort label which is a weak fit per the legend — consider a Remove row.
• Prohibition is only human-discoverable; worth a follow-up conformance check asserting no envelope property matches /^(task|response)_status$/.
• "or any alias" is undefined across the three surfaces — enumerate known aliases or tighten the rule.