fix(schema,skill): align HMAC framing to RFC 9421 default in reporting-webhook, auth-scheme, call-adcp-agent SKILL.md

[bokelley]

Refs #4270

Summary

Closes the on-ramp framing gap identified in #4270 — surface 4 of the HMAC→RFC 9421 migration checklist (@bokelley's four-surface plan from #4205):

• reporting-webhook.json: authentication.schemes description called HMAC-SHA256 "recommended for production" and authentication description had no deprecation signal. Fixed to match push-notification-config.json framing: both schemes are deprecated, RFC 9421 is the preferred profile. Since authentication remains in required[] in 3.x, the description now says explicitly "This field is required in AdCP 3.x; the requirement is removed in AdCP 4.0."
• auth-scheme.json: Enum description was silent on deprecation. Updated to label both values as legacy, note that RFC 9421 is the default when authentication is optional, and that both are removed in 4.0.
• skills/call-adcp-agent/SKILL.md: Added "Webhook signing — omit authentication for new integrations" section under "Non-obvious rules every buyer must follow." Closes the silent-default trap: a buyer agent reading only the SKILL.md previously had no guidance that omitting authentication selects the RFC 9421 default; reaching for the visible field in the schema would opt the seller into the deprecated HMAC path.

Non-breaking justification

Description-only changes. No field added or removed, no required arrays changed, no enum values added or removed, no wire behavior change. authentication remains required in reporting-webhook.json in 3.x — the schema structure is unchanged. Changeset: patch.

What is NOT in this PR (flagged for human review)

Two items from #4270 require human/WG decisions before landing:

1. Making authentication optional in reporting-webhook.json — removing from required[] is a signing-profile change (playbook: "never patch-eligible: signing profile changes"). Needs minor bump and security doc update to explicitly cover reporting_webhook signing-mode selection. Routed to 3.1.x. The open question (per protocol-expert review): does the webhook_mode_mismatch downgrade-resistance rule already apply to reporting webhook registrations, or does the security doc need to be extended?

2. artifact_webhook in create-media-buy-request.json — protocol-expert found the same stale "recommended for production" framing on the authentication.schemes description there. Not in scope of this PR to keep the change bounded; should be a follow-up.

Pre-PR review

• code-reviewer: approved — all blockers resolved (dead link reverted, required-constraint contradiction fixed, adagents.json → brand.json corrected per security.mdx §webhook-callbacks); two nits noted (link wraps across two lines in SKILL.md, changeset description updated)
• ad-tech-protocol-expert: approved — non-breaking per spec; description-only; brand.json is correct for buyer JWKS discovery (security.mdx line 1176, 1201-1206); authentication required constraint intact; changeset patch correct

Milestone note: gh CLI unavailable in this run environment — could not confirm the open 3.0.x patch milestone. Please set milestone to the active patch target before merge.

Triage-managed PR. This bot does not currently iterate on
review comments or PR conversation threads (only on the source
issue). To unblock:

• Push fixup commits directly: gh pr checkout <num> →
  fix → push.
• Or re-trigger: comment /triage execute on the source
  issue.

See #3121
for context.

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

---

Generated by Claude Code