Backport proposal support gate to 3.0.x

[bokelley]

Summary

Backports the proposal-finalize storyboard applicability gate to the 3.0.x release line.

• Adds requires_capability to the 3.0.x proposal_finalize storyboard.
• Treats absent media_buy.supports_proposals as false, so sellers without proposal support skip the scenario instead of failing.
• Does not add media_buy.supports_proposals to the 3.0.x schema, preserving the stable-schema patch rule.
• Adds a patch changeset.

Fixes #5256.

Validation

• npm run build:compliance
• precommit hook: npm run test:unit, npm run test:test-dynamic-imports, npm run typecheck
• push hook: version sync

[aao-release-bot]

Faithful backport — the gate block is byte-identical to the 3.1 version on main, and the applicability semantics are right: an optional capability surface that a seller never claimed shouldn't grade as a failure. The open question is whether the 3.0.x runner actually honors it.

Things I checked

• Gate is byte-identical to main. proposal_finalize.yaml:11-15 matches origin/main's block exactly (path: media_buy.supports_proposals, equals: true). Clean backport, no shape drift.
• The field is real and load-bearing on 3.1. requires_capability is used in 26 source scenarios on main, and universal/runner-output-contract.yaml documents gate-false → not_applicable ("a scenario's requires_capability check found an optional capability set to false… detail MUST cite the failed gate"). So on the line where it's honored, the skip surfaces as not_applicable, not a silent pass — no hidden conformance gap. ad-tech-protocol-expert: sound-with-caveats, on exactly this point.
• Build preserves the field. scripts/build-compliance.cjs copies scenario YAML verbatim (copyTree → fs.copyFileSync, build-compliance.cjs:80-90), so the gate reaches the published dist suite intact — it is not stripped by a key allowlist.
• Date bump is consistent. All five idempotency phases bumped uniformly 2026→2027 (idempotency.yaml:191,266,344,464,527), no orphaned 2026 dates. The two replay steps stay byte-identical (both 2027-06-30/5000), and the conflict step still differs on both end_time (2027-09-30) and budget (25000) — byte-identical replay and the IDEMPOTENCY_CONFLICT negative test both hold. The comment at L432 ("a different end_time") stays accurate.
• Changeset. Present, patch, correct — no schema or wire change; media_buy.supports_proposals is deliberately not added to the 3.0 schema.

The open question — what flips this to approve

main runs @adcp/sdk@9.x. 3.0.x pins @adcp/client@5.21.1 (package.json) — a different runner package. The proof that requires_capability is honored comes entirely from the SDK-9 line; it does not transfer to the client-5.21.1 runner. On 3.0.x this is the first and only use of requires_capability, and the 3.0.x runner-output-contract.yaml does not document the field (it does on main).

If @adcp/client@5.21.1 doesn't evaluate requires_capability, the block is inert: the scenario runs against non-proposal 3.0.x sellers, get_products in refine/finalize mode fails, and they keep getting the exact false-negative #5256 is meant to remove. Fail-open, in the direction the PR is trying to close.

The validation section lists build:compliance, unit, typecheck, version-sync — none of which exercise the gate. The primary user-facing behavior of this PR (non-proposal seller now skips instead of failing) ships unvalidated against the path it claims to fix.

To flip to approve, confirm one of:

1. @adcp/client@5.21.1 evaluates requires_capability and grades the gated scenario not_applicable (a one-line pointer to the client release that landed it is enough), or
2. a compliance-suite run on 3.0.x against a non-proposal seller showing proposal_finalize grades not_applicable instead of failing.

I couldn't verify the client version from the diff (npm/registry access is sandboxed here), so this is an open question, not a block — if 5.21.1 honors the field, the PR is correct and clean as written.

Minor nits (non-blocking)

1. Hardcoded flight dates will rot again. The 2026→2027 bump is the second time these dates have been chased forward; a relative-offset helper (now + N days) in the runner would end the treadmill. Follow-up, not this PR.