fix(decisioning): get_adcp_capabilities response must include account.supported_billing when seller claims media_buy

[bokelley]

Context

protocol/get-adcp-capabilities-response.json (lines 132-173) requires account.supported_billing to be present whenever the seller claims media_buy. The v3 reference seller declares:

DecisioningCapabilities(
    specialisms=("sales-non-guaranteed",),
    channels=("display", "video"),
    pricing_models=("cpm",),
)

…with no supported_billing declaration anywhere. Either the framework is silently projecting this from somewhere (e.g. BuyerAgent.billing_capabilities) and we should verify, or the framework is silently emitting an out-of-spec capabilities response.

Refs:

• src/adcp/decisioning/capabilities.py
• examples/v3_reference_seller/src/platform.py
• protocol/get-adcp-capabilities-response.json:132-173

Acceptance Criteria

• Audit current get_adcp_capabilities response — confirm whether account.supported_billing is populated
• If missing: add it to DecisioningCapabilities (or wherever the projection happens) and wire through to the response
• If BuyerAgent.billing_capabilities is the source, document that and ensure the v3 ref seller sets it
• Schema-validate the capabilities response against get-adcp-capabilities-response.json in CI
• Boot-time validator rejects platforms that claim media_buy without declaring supported_billing

[bokelley]

Triage complete. Draft PR: #397.

Root cause confirmed: PlatformHandler had no get_adcp_capabilities shim — it fell through to ADCPHandler._not_supported() — and DecisioningCapabilities had no supported_billing field, so there was no way to project account.supported_billing into the response even if the shim existed.

Fix: Non-breaking. supported_billing: list[str] defaults to []; existing sellers without it continue to boot (with a new UserWarning) rather than hard-failing. The shim auto-derives supported_protocols from claimed specialisms.

One open question for human reviewer (flagged in PR): whether the boot-time check should be a hard AdcpError (consistent with the governance specialism precedent) or remain a UserWarning with a stated promotion timeline. The spec says "should" not "must" for account.supported_billing, which is the basis for the softer approach.

---

Generated by Claude Code