feat(schema): add VAST 4.3 to the VAST version enum

[aleksUIX]

Summary

enums/vast-version.json tops out at 4.2. IAB Tech Lab released VAST 4.3 in December 2022, so a creative manifest that declares the version its document actually carries fails validation today:

pre-change  (2.0-4.2): vast_version "4.3" -> REJECTED
post-change (2.0-4.3): vast_version "4.3" -> ACCEPTED

(ajv, built core/assets/vast-asset.json, asset {asset_type: "vast", delivery_type: "url", url: "...", vast_version: "4.3"}.)

The practical effect is that a buyer trafficking a 4.3 tag has to declare "4.2". That is a data-integrity problem on its own, and it becomes a correctness problem for any seller that compares the declared vast_version against the version attribute on the document root.

Why this clears the enum-membership bar

docs/spec-guidelines.md treats adding an enum value as a curation decision, with a dialect test that cosmetic or additive-optional differences do not pass. VAST 4.3 is a thin release, so that question is fair to ask.

It clears the bar for a different reason than feature weight:

• The enum already carries 2.0 and 3.0. If the roster were curated by feature materiality, deprecated versions would not be members. It is the published-version list.
• vast_version mirrors the version attribute a VAST document declares on its root element. It is not a dialect selector, so the value has to exist to be declarable at all.
• Published, stable, industry-wide: IAB Tech Lab, December 2022 (public comment September 2022), relevant across every video producer and consumer by construction.
• There is also one consumer-visible delta: InteractiveCreativeFile content may be an inline data: URI in 4.3, which a strict 4.2 consumer can mis-handle.

Change

• enums/vast-version.json: add "4.3". Description and $comment record two things implementers get wrong.
• core/requirements/vast-asset-requirements.json and formats/canonical/video_vast.json restated the version list inline. Both now $ref the shared enum, per the Enum Consolidation rule in docs/spec-guidelines.md. The duplication is what let the list drift for four years.
• Prose alignment: creative/asset-types/index.json (plus lastUpdated), index.json, docs/creative/asset-types.mdx, docs/protocol/get_adcp_capabilities.mdx (field table + example).

VAST 4.3 ships no XSD of its own. IAB's vast_4.2.xsd remains the authoritative schema for 4.3 documents. The $comment says so explicitly, so a document-level validator does not reject version="4.3" for want of a 4.3 schema.

VAST 4.4 is deliberately excluded. vast_4.4.xsd exists in the IAB VAST repository but is annotated "DRAFT for working group discussion". A draft version in a normative enum would let buyers declare a version whose semantics can still change. The $comment records the condition for adding it later.

Relationship to #5820

#5820 (open) specifies a document validation level that checks the tag's declared version against the asset's vast_version. Without this enum change, a valid 4.3 tag forces a mis-declaration and then trips that check, so this PR is a prerequisite for it rather than an overlap. The two do not touch the same files.

Deliberate non-changes

• creative_specs.vast_versions in get-adcp-capabilities-response.json is an open ^[0-9]+\.[0-9]+$ pattern, not this enum. A seller can advertise a version that buyers cannot express in a manifest. Tightening it to $ref the enum would break anyone currently advertising a value outside the roster, so it is worth a separate decision. Happy to follow up if reviewers want it aligned.
• server/src/shared/formats.ts hardcodes vast_versions: ['3.0','4.0','4.1','4.2'] on four reference formats. That is a seller's declared acceptance list, and capping at 4.2 is a legitimate seller choice, so it is left alone rather than pulling server code into a schema PR.
• registries/v1-canonical-mapping.json still maps >=4.0 to vast_version: "4.2", which stays correct under its lowest-common-denominator note.

Verification

build-schemas clean, $ref resolves to an absolute URL in dist/schemas/latest/. Passing: schema-validation (20/20), json-schema-validation (284/284), canonical-fixture-validation (15/15), canonical-format-conventions, mcp-schema-projection (7/7), composed-schema-validation (139/139), example-validation-simple (55/55), migration-validation, precommit:server-unit (5106 passed).

Two local failures were verified pre-existing by re-running on a clean main with the branch stashed: tests/sdk-safe-fetch.test.ts (local MCP discovery) and server/src/utils/otel-logs.ts TS2561. snippet-validation reports 37 failures on this branch and 37 on clean main.

[aao-secretariat]

Ladon verdict: Escalate to human review

Escalate — gated paths touched without required review approval.

This PR adds VAST 4.3 to the shared enums/vast-version.json and consolidates two inline rosters onto a $ref to the shared enum, with schema↔docs coherence verified (asset-types.mdx, get_adcp_capabilities.mdx track the new value; open string pattern already admits 4.3). The change is additive, carries a correct minor changeset, leaves the oneOf baseline unaffected, and does not touch dist/**. The reviewer surfaced no critical/high/medium findings — mechanically clean.

However, five files under static/schemas/source/** are modified, which places this PR under the deterministic hard approval gate (gated_paths: true). review_decision is REVIEW_REQUIRED, not APPROVED, so the gate is not satisfied. Per decision rule row 2, the outcome must be escalate — human/CODEOWNERS review is required before merge.

Escalation reasons

• Modifies gated files under static/schemas/source/** (vast-version.json, vast-asset-requirements.json, video_vast.json, asset-types/index.json, index.json); requires human/CODEOWNERS approval — review_decision is currently REVIEW_REQUIRED.

No blocking code findings; the gate lifts once a required review approves.

Why human review

• Modifies gated files under static/schemas/source/** (vast-version.json, vast-asset-requirements.json, video_vast.json, asset-types/index.json, index.json) — hard approval gate requires human/CODEOWNERS review; review_decision is REVIEW_REQUIRED, not APPROVED.
• This PR touches a path under a hard, non-overridable approval gate (static/schemas/source/core/requirements/vast-asset-requirements.json (modified) matches static/schemas/source/**; static/schemas/source/creative/asset-types/index.json (modified) matches static/schemas/source/**; static/schemas/source/enums/vast-version.json (modified) matches static/schemas/source/**; static/schemas/source/formats/canonical/video_vast.json (modified) matches static/schemas/source/**; static/schemas/source/index.json (modified) matches static/schemas/source/**) and the current GitHub review decision is 'REVIEW_REQUIRED', not APPROVED. This is a hard gate enforced in code — Ladon cannot auto-approve until a human/CODEOWNERS approval is recorded, regardless of how clean the diff is.

[bokelley]

Reviewed the enum and documentation changes against current repository conventions. VAST 4.3 is a published root-document version, 4.4 remains draft, duplicated inline enums now correctly reference the canonical enum, and the minor changeset is appropriate. The prior red code_review was solely the external-contributor permission failure; refreshed CI is clean so far.