feat(compliance): add vendor_metric optimization-goal storyboard coverage

[bokelley]

Closes #4933

Adds storyboard coverage for the 3.1 vendor_metric optimization goal contract, which was missing from the compliance suite. A seller could previously pass the existing vendor_metric_accountability storyboard without proving it enforces the 3.1 optimization-goal acceptance/rejection rules.

Changes

New storyboard static/compliance/source/protocols/media-buy/scenarios/vendor_metric_optimization_flow.yaml:

• Positive path: kind: "vendor_metric" goal accepted when (vendor, metric_id) is in vendor_metric_optimization.supported_metrics[], target.kind is in supported_targets, and package has a matching vendor-scope committed_metrics[] entry
• Negative path A: goal rejected (INVALID_REQUEST) when (vendor, metric_id) is not in the product's supported_metrics
• Negative path B: goal rejected (INVALID_REQUEST) when optimization goal is capability-valid but the package has no vendor-scope committed_metrics entry (reporting-coherence precondition failure — distinct from a TERMS_REJECTED committed_metrics over-proposal)
• Discovery SHOULD (path 5 from issue — seller SHOULD verify metric_id in vendor's catalog) documented in narrative; not asserted as failing since the spec is SHOULD-level in 3.1

Training-agent fixtures (server/src/training-agent/):

• types.ts: added vendorMetricOptimization optional field to PublisherProfile
• publishers.ts: added attention_score to pinnacle_news vendorMetrics and vendorMetricOptimization.supported_metrics
• product-factory.ts: spread vendor_metric_optimization onto the product build alongside the existing metric_optimization pattern

Non-breaking justification: entirely additive — new storyboard file, new optional TypeScript field, new publisher capability entry; no existing storyboard, schema, or publisher profile is modified.

Pre-PR review:

• code-reviewer: approved — blocker fixed (renamed key: to name: in context_outputs); nit noted (TypeScript type could be tighter, low risk)
• ad-tech-protocol-expert: approved — INVALID_REQUEST confirmed correct for both negative paths; path B narrative clarified to distinguish reporting-coherence precondition failure from TERMS_REJECTED committed_metrics over-proposal; omitting requires_capability is correct since vendor_metric_optimization is product-level only

Nits (not fixed): one unexercised MUST-level path (target.kind not in supported_targets) surfaced by review — flagged for follow-up issue rather than scope-expanding this PR.

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_01VtKu8sAUEWAHRPMiZJBgHw

---

Generated by Claude Code

[bokelley]

Taking this out of draft. This looks like merge-track compliance coverage rather than a parking-lot draft; leaving it for normal review.

[bokelley]

Acknowledged — noted that you've moved this to normal review. No action from triage; this PR stands as documented.

---

Generated by Claude Code

[bokelley]

Closing as superseded. The substantive changes from this PR are already on main: vendor_metric_optimization_flow exists in static compliance source and released bundles, and the training-agent product factory/publisher/type support is present. This branch now conflicts with main and no longer needs to merge separately.

[aao-release-bot]

LGTM. Compliance-gap closure on the 3.1 vendor_metric contract, additive only, two negative paths exercising the right MUST preconditions.

Things I checked

• Schema conformance. Storyboard wire shapes match static/schemas/source/core/optimization-goal.json:183-225 (goal structure) and static/schemas/source/core/vendor-metric-optimization.json:1-40 (capability declaration). target.kind: "threshold_rate" + numeric value, committed_metrics[{scope: "vendor", ...}], and the (vendor.domain, metric_id) key threading across discovery / capability / commitment / optimization are all correct.
• Error codes. ad-tech-protocol-expert confirmed INVALID_REQUEST is the right code for both negative paths. Path B's distinction (reporting-coherence failure on the goal vs. committed_metrics over-proposal → TERMS_REJECTED per package-request.json:107) is sound — that prose is load-bearing.
• Discovery SHOULD. Documented in the narrative, not asserted as a failing path. Right call per the explicit SHOULD-level language in optimization-goal.json:183.
• Symmetry. attentionvendor.example / attention_score threaded through reporting_capabilities.vendor_metrics, vendor_metric_optimization.supported_metrics, the goal, and the package's vendor-scope committed_metrics. Same (vendor, metric_id) on all four surfaces.
• Training-agent TS. vendorMetricOptimization shape (server/src/training-agent/types.ts:98-105) matches the schema. Spread in product-factory.ts:565 follows the metric_optimization precedent on the line directly above it. publishers.ts:33-43 adds the symmetric reporting + optimization entries for pinnacle_news — that pairing is required for the positive path's reporting-coherence precondition, not duplication.
• Changeset. Empty-frontmatter form matches repo convention for non-package-bump changes (precedent: .changeset/2383-test-vector-index-scope-update.md).
• code-reviewer: clean.
• ad-tech-protocol-expert: sound-with-caveats, no wire-shape drift.

Follow-ups (non-blocking — file as issues)

• Path A confounding variable. reject_unsupported_capability submits an emissions_score goal and a committed_metrics entry for the same metric. emissions_score is also absent from the product's reporting vendor_metrics, so a conformant seller could legitimately emit TERMS_REJECTED on the committed_metrics over-proposal (per package-request.json:107) before ever reaching the optimization-goal capability check — and would correctly fail this storyboard. Either drop committed_metrics from path A, or seed a publisher case where a metric is in vendor_metrics but not in supported_metrics so the capability check is isolated.
• Unexercised MUST: target.kind not in supported_targets. Already acknowledged in the PR body. MUST-reject per vendor-metric-optimization.json. File and link.
• Schema silence on error codes. Neither optimization-goal.json:183 nor vendor-metric-optimization.json pins the rejection code to INVALID_REQUEST. The storyboard's choice is defensible and consistent with how other capability-table checks are framed, but the storyboard would rest on firmer ground if the schema named the code in the MUST-reject prose.

Minor nits (non-blocking)

1. supported_targets type drift risk. server/src/training-agent/types.ts:99 hard-codes Array<'cost_per' | 'threshold_rate'>. Derive from NonNullable<Product['vendor_metric_optimization']>['supported_metrics'][number]['supported_targets'] once the SDK exposes it.
2. Path A narrative. A one-line note that the duplicated committed_metrics is intentional (to isolate the capability check) would help future readers — though the Follow-up above would obviate the comment if taken.

Approving.