feat(reporting): add time_based_views with a basis discriminator

[bokelley]

Summary

Stacked on #6618 (base retargets to main automatically when it merges). Implements RFC #6430.

Adds time_based_views to delivery-metrics: an array of time-threshold video view counts, one entry per (threshold_seconds, basis). This is the primary view currency for autoplay/skippable video (social, olv, in-feed display video, retail media video) that delivery reporting could not represent — quartile_data is percentage-based and views is a single billable-threshold scalar.

The semantic fix beyond the RFC

The RFC's shape ({threshold_seconds, views}) conflated metrics that are not interchangeable: Meta's 2-second video view is continuous play time with no viewport requirement, while IAB/MRC viewable video is continuous in-view time (50% of pixels). Same threshold, materially different numbers. The new view-threshold-basis enum (play_time | in_view) is a required per-entry discriminator, with normative MUST NOT sum/conflate language — the same class of incompatible-definition protection the committed_metrics qualifier system provides elsewhere. The enum is deliberately extensible (an audible-playback basis for audio verified-listen thresholds can ship later without reshaping the array), resolving RFC open question 4 in favor of video-only-now without foreclosing audio.

Design decisions

• Array, not discrete fields — thresholds are open-ended and platform-specific (RFC's own recommendation). 2s/6s are RECOMMENDED cross-platform points, any threshold permitted.
• Dedup by normative prose — one entry per (threshold_seconds, basis), seller MUST de-duplicate, buyers MAY treat duplicates as a conformance bug (mirrors the vendor_metric_values rule; draft-07 uniqueItems can't enforce tuple-level uniqueness). Resolves RFC open question 3.
• Not sortable — array entries are excluded from sort_by by design; per-threshold sorting would need the qualified-selector mechanism and can ride a later minor if demand materializes (noted in the schema description).
• Explicitly not a CTV/cinema metric — completion remains the lean-back currency; stated in schema and docs.

Capability-gated via the time_based_views token in available-metric. Contract test covers shape validation, enum membership (in available-metric, not in sort-metric), and the normative-language anchors.

🤖 Generated with Claude Code

[aao-secretariat]

Ladon verdict: Escalate to human review

Escalate — gated-path change requires human/CODEOWNERS approval.

This PR is an additive Normative change: it adds time_based_views (array of {threshold_seconds, basis, views}) to core/delivery-metrics.json, introduces a new view-threshold-basis enum (play_time|in_view), and adds an available-metric token. The reviewer found the schema, both media-buy delivery docs pages, the minor changeset, the $ref-based enum, and the new contract test all cohere — no oneOf regression, no breaking wire change, no schema↔docs drift. No Medium-or-worse findings.

However, this PR modifies/adds files under static/schemas/source/**, which is a deterministic hard approval gate (gated_paths: true). review_decision is not APPROVED, so the gate is not satisfied and the outcome cannot be approve (decision table row 2). Because the diff is otherwise clean with no blocking findings, this escalates for explicit human/CODEOWNERS sign-off rather than requesting changes.

Escalation reasons

• gated_paths hard gate unsatisfied: PR touches static/schemas/source/core/delivery-metrics.json, static/schemas/source/enums/available-metric.json, and adds static/schemas/source/enums/view-threshold-basis.json, and review_decision is not APPROVED. Human/CODEOWNERS review of the protocol source-of-truth change is required before merge.

Why human review

• Gated path (static/schemas/source/**) modified/added with review_decision not APPROVED — human/CODEOWNERS review required for the protocol schema change (delivery-metrics.json, available-metric.json, new view-threshold-basis.json).
• This PR touches a path under a hard, non-overridable approval gate (static/schemas/source/core/delivery-metrics.json (modified) matches static/schemas/source/**; static/schemas/source/enums/available-metric.json (modified) matches static/schemas/source/**; static/schemas/source/enums/view-threshold-basis.json (added) matches static/schemas/source/**) and the current GitHub review decision is 'unknown', 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.

[aao-secretariat]

Ladon verdict: Escalate to human review

Escalate — protocol schema change under a hard approval gate with no recorded human/CODEOWNERS approval.

This PR modifies and adds files under static/schemas/source/** (delivery-metrics.json, available-metric.json, sort-metric.json, and the new view-threshold-basis.json), which are gated paths. gated_paths is true and review_decision is not APPROVED (unknown/none), so the hard approval gate (decision-table row 2) is not satisfied and I cannot auto-approve.

The reviewer found no critical/high/medium findings in this delta: the added standard field is optional/RECOMMENDED-only (not a required/rename/retype/enum-value change), schema↔docs coherence holds, sort-metric correctly excludes time_based_views, and a changeset is present. The change appears clean and non-breaking — but the gate lifts only on a real human/CODEOWNERS approval, not because the diff looks safe.

Escalation reasons

• Gated path (static/schemas/source/**) modified/added with review_decision not APPROVED — human/CODEOWNERS review required for the protocol schema change (delivery-metrics.json, available-metric.json, sort-metric.json, new view-threshold-basis.json).
• Sticky: prior decision was escalate for the same gate; the gate remains unsatisfied.

Why human review

• Gated path static/schemas/source/** modified/added (delivery-metrics.json, available-metric.json, sort-metric.json, new view-threshold-basis.json) with review_decision not APPROVED — human/CODEOWNERS approval required before this protocol schema change can merge.
• Prior decision was escalate for the same hard approval gate and the gate condition still holds (review_decision unknown/none).
• This PR touches a path under a hard, non-overridable approval gate (static/schemas/source/core/delivery-metrics.json (modified) matches static/schemas/source/**; static/schemas/source/enums/available-metric.json (modified) matches static/schemas/source/**; static/schemas/source/enums/sort-metric.json (modified) matches static/schemas/source/**; static/schemas/source/enums/view-threshold-basis.json (added) matches static/schemas/source/**) and the current GitHub review decision is 'unknown', 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.