feat(schemas): add supported_target_kinds to conversion_tracking capability (closes #4639)

[bokelley]

Summary

Adds an optional supported_target_kinds array to the existing seller-level conversion_tracking capability object on get_adcp_capabilities. Enum-constrained to cost_per | per_ad_spend | maximize_value, paralleling the product-level metric_optimization.supported_targets.

Why

Today the spec requires sellers to reject target.kind: per_ad_spend event goals when no event_sources[] entry carries value_field (per static/schemas/source/core/optimization-goal.json), but buyers have no pre-submission signal — they discover the constraint only at create_media_buy rejection time. With this capability declaration:

• Buyers can filter their event-goal shape against the seller's supported kinds before submission.
• Sellers MUST reject goals whose target.kind is not listed (when the property is present).
• Omission preserves today's semantics: only target-less event goals (maximize conversion count within budget) are guaranteed; sellers MAY accept specific kinds but buyers should not rely on it.
• A future capability-gated performance_buy_flow_roas storyboard scenario can gate on this without coupling to this schema PR.

Out of scope

• Per-event-type matrix (i.e. "ROAS supported on purchase but not lead"). The existing one-dimensional capability is good enough for the buyer pre-filter; finer granularity can be a follow-up if implementer feedback demands it.
• The companion storyboard scenario (performance_buy_flow_roas) — lands in a separate PR after this merges.

Compatibility

Purely additive: new optional property, no existing field touched, no enum tightened, no required list changed. additionalProperties: true on conversion_tracking was already the policy.

Refs

• RFC: performance-sales specialism — is conversion-driven selling distinct from sales-social? #4569 — media_buy_seller/performance_buy_flow scenario (CPA) that this unblocks the ROAS counterpart for
• Meta: capability-claim contract scenarios — close the gap between what agents declare and what they do #4637 — performance buy flow umbrella
• Add media_buy.conversion_tracking.supported_target_kinds capability declaration #4639 — this issue

Test plan

• npm run build:schemas succeeds, latest bundle regenerated
• npm run build:compliance succeeds (no compliance source touched but sanity-checked)
• Precommit (unit + dynamic-imports + callapi-state-change + typecheck) green
• CI passes on the PR

🤖 Generated with Claude Code

[bokelley]

Renamed supported_target_kinds → supported_targets per protocol-review feedback.

Why: the original name diverged from the existing product-level field metric_optimization.supported_targets (static/schemas/source/core/product.json) for the identical concept (which event-goal target.kind values are supported). Two names for the same concept is a naming smell, and field names are public API — easier to fix pre-merge than after.

What changed:

• conversion_tracking.supported_target_kinds → conversion_tracking.supported_targets in static/schemas/source/protocol/get-adcp-capabilities-response.json. Same enum (cost_per | per_ad_spend | maximize_value), same minItems: 1 + uniqueItems: true, same purely-additive backward-compatibility posture.
• Description now explicitly notes the parallel to metric_optimization.supported_targets at the product level (same concept, seller-capability granularity vs. product granularity).
• Changeset file renamed to .changeset/4639-conversion-tracking-supported-targets.md; body updated to match.

Not in this PR: docs cross-refs between the two fields are deferred to a follow-up.

npm run build:schemas and npm run build:compliance both pass on the new commit (6fb921e).