fix(decisioning): add supported_billing to DecisioningCapabilities + capabilities shim

[bokelley]

Summary

Fixes #379. DecisioningCapabilities had no supported_billing field, and PlatformHandler had no get_adcp_capabilities shim at all (fell through to _not_supported()). Every sales-* seller was either returning a 501 or emitting a capabilities response that fails get-adcp-capabilities-response.json schema validation — the schema requires account.supported_billing (minItems: 1) for any seller claiming the media_buy protocol.

• DecisioningCapabilities gains supported_billing: list[str] (default [], non-breaking)
• PlatformHandler gains a get_adcp_capabilities shim that auto-derives supported_protocols from claimed specialisms via a new SPECIALISM_TO_PROTOCOL map and projects account.supported_billing when non-empty
• validate_platform() now emits a UserWarning at server boot when a sales-* platform declares no supported_billing
• capabilities_response() gains an account kwarg (non-breaking, keyword-only)
• v3 reference seller updated with supported_billing=["operator"]
• 3 new handler tests: billing projection, omit-account-when-empty, and full JSON Schema validation against the bundled schema

Pre-PR review notes

Two expert subagents reviewed the diff before this PR was opened. Issues addressed and left open:

Fixed (post-review):

• Removed audience-sync from SPECIALISM_TO_PROTOCOL. Both reviewers flagged this: an audience-sync-only agent cannot fulfill get_products / create_media_buy / etc., so advertising media_buy in supported_protocols without those tools is a buyer-visible lie. A co-claimed sales-* specialism drives the media_buy declaration when needed.

Open for human reviewer decision:

• UserWarning vs hard fail for empty supported_billing on sales-* platforms. The protocol expert argues for a hard fail (consistent with the governance specialism precedent in the same function). The code reviewer considers a soft warn appropriate here. The spec language is "should" not "must" (schema lines 133–135), which is the basis for the soft warn. The PR uses UserWarning with an explicit "will become a hard fail in a future minor" note. Reviewer should decide: promote to AdcpError now, or accept the staged approach?
• idempotency={"supported": False} default. The shim always emits this to satisfy adcp.idempotency required in the schema. The protocol expert noted adopters who want to upgrade to supported: true must override the entire get_adcp_capabilities method; a future improvement could expose a lighter hook. Out of scope for this fix; noted in the docstring.

Triage-managed PR

This PR was opened by the automated triage agent in response to issue #379 filed by @bokelley.

• Change classification: bug fix, non-breaking (new field defaults to []; new shim fills a gap that was returning 501)
• All three pre-commit gates pass: ruff check ✓, mypy --ignore-missing-imports ✓, pytest 99/99 ✓

https://claude.ai/code/session_01HxAzzPmnEpEfexwZW3Wksj

---

Generated by Claude Code