feat(compliance): add optional audio build phase to creative_template storyboard

[bokelley]

Closes #4015

Summary

Audio-creative platforms (TTS services, voice generation agents, mix/master pipelines) could not pass the creative_template storyboard because its build phase sends image inputs and expects display-tag output. They validated via manual round-trip + SDK tests only — no formal compliance signal.

This PR adds an optional audio_build phase with a single build_audio_creative step that exercises build_creative with audio inputs (script text, voice descriptor, click URL) and validates that the output carries a creative manifest with assets. Both sync returns and task-envelope async returns (submitted → working → completed) are valid under the existing comply_scenario: creative_flow gate.

Files changed:

• static/compliance/source/specialisms/creative-template/index.yaml — new audio_build phase appended
• static/compliance/source/test-kits/acme-outdoor.yaml — supports_audio_formats flag + assets.audio reference block

Non-breaking justification

Additive scenario only: no existing phases or steps are modified. The new phase is marked optional: true and gated by skip_if: "!test_kit.supports_audio_formats", which defaults to false in acme-outdoor.yaml. Display-only template agents grade the phase not_applicable with zero behavior change. Per the conformance-harness patch-eligibility rules in the playbook, additive storyboard scenarios are non-breaking.

Pre-PR review

• code-reviewer: approved (1 nit — test-kit assets.audio comment clarified; 1 blocker fixed — added optional: true to phase)
• ad-tech-protocol-expert: approved — asset_type: "text" without sub-discriminator is consistent with existing headline pattern in the same storyboard; audio asset type is registered in static/schemas/source/creative/asset-types/index.json; click_url key name matches existing display build steps; skip_if scope is correct (static test-kit flag, not runtime response data); changeset correctly uses --empty

Note (nit, not blocking): The validations block cannot assert a specific output audio asset key because the key name is format-defined, not protocol-defined. The expected prose is normative on this: "A creative manifest with an audio asset (asset_type: audio) and a resolvable URL." A runner that supports key-agnostic anyOf(asset_type: audio) scanning could enforce this at the harness level as a follow-up.

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_013KNxYsZtapmfcVndMGx1Tw

---

Generated by Claude Code