schemas(reporting-webhook, auth-scheme): deprecate HMAC-SHA256 recommendation, point at RFC 9421

[EvgenyAndroid]

First pass on the schema-description sub-item of #4270 (storyboard / SDK-skill on-ramp inventory). Surgical, source-only, no normative change — mirrors precedent #2506.

Why

push-notification-config.json's authentication field was already updated in #2506 to mark Bearer / HMAC-SHA256 as the deprecated legacy fallback removed in AdCP 4.0, with RFC 9421 as the default. Two adjacent schemas were left out of that pass and still steer new buyers toward the HMAC on-ramp:

• static/schemas/source/core/reporting-webhook.json — authentication.schemes description literally says HMAC-SHA256 is "recommended for production". Contradicts push-notification-config.json. Active mis-direction for any new buyer reading the schema in isolation.
• static/schemas/source/enums/auth-scheme.json — enum-level description doesn't mention deprecation at all. SDK authors loading the enum without cross-referencing push-notification-config.json have no signal these are legacy options.

What this PR does

1. reporting-webhook.json (1 line): replace "['HMAC-SHA256'] for signature verification (recommended for production)" with the same "both deprecated, removed in 4.0, see push-notification-config" framing already used in push-notification-config.json.
2. auth-scheme.json (1 line): extend the description to state these enum values are scoped to the legacy authentication block and point readers at the RFC 9421 default.
3. .changeset/4270-deprecate-hmac-recommendation-in-schemas.md: changeset entry.

No dist/ regen; static/schemas/source/ is the source of truth and build:schemas regenerates dist/ at release.

What's NOT in this PR (deliberately scoped out — maintainer call)

reporting-webhook.json has authentication in required: [...]. That's a structural asymmetry vs push-notification-config.json (where the block is optional and absence selects 9421). Today there is no opt-in path to RFC 9421 for reporting webhooks — every reporting buyer is forced through the legacy auth block.

That's a normative question, not a description fix, so it stays in #4270 for triage. If the spec intends symmetry with push-notification-config.json, follow-up PR drops \"authentication\" from the required array and mirrors push-notification-config's framing on the field. Happy to take that as a follow-up if maintainers triage favorably.

Test plan

• static/schemas/source/core/reporting-webhook.json parses (JSON syntactically valid, no schema shape change)
• static/schemas/source/enums/auth-scheme.json parses
• No dist/ files modified — release build regenerates from source
• CI: schema-validation, json-schema-validation, lint-schema-links (will run on PR)

Cross-references

• Storyboard / SDK skill on-ramp inventory: HMAC vs RFC 9421 #4270 (parent — storyboard / SDK-skill on-ramp inventory)
• schemas(push-notification-config): state legacy/9421 precedence in authentication field #2506 (precedent — same shape of edit on push-notification-config.json)
• [meta] Coordinate RFC 9421 webhook signing migration — adoption telemetry + threshold + ownership #4205 (RFC 9421 webhook signing migration coordination — on-ramp framing)
• spec(webhooks): unify webhook signing on RFC 9421 profile #2423 (original 9421 unification PR)

I have read the IPR Policy

[EvgenyAndroid]

I have read the IPR Policy

[aao-ipr-bot]

IPR Policy Agreement Required

@EvgenyAndroid — thanks for the contribution. Before this PR can be merged, the AgenticAdvertising.Org IPR Policy requires your agreement.

To agree, post a new comment on this PR with the exact phrase:

I have read the IPR Policy

Your signature is recorded once and covers all contributions to AAO repositories. See signatures/README.md for what gets recorded and why.

[EvgenyAndroid]

I have read the IPR Policy

[aao-ipr-bot]

IPR Policy — signed

Thanks, @EvgenyAndroid. Your agreement to the IPR Policy is recorded at signatures/ipr-signatures.json and applies to all AAO repositories.

[EvgenyAndroid]

Deferring to #4271 per @bokelley's triage comment on #4270. #4271 is atomic, targets 3.0.x correctly (mine targeted main), and the parent authentication.description rewrite there resolves the structural question I deferred — "required in AdCP 3.x; the requirement is removed in AdCP 4.0 when the default RFC 9421 path becomes the only path" — which is the right answer. Closing this PR.