adcp/v3: generate list_products types (the response's oneOf only switches required fields) #599

list_products is the last 3.2 media-buy lifecycle task without generated types, after #563, #589 and #596. The request generates with two small overrides; the response needs a generator decision first, so I'm raising it here before any code.

What happens today

Checked on main (bb0fe57) against the pinned 3.2.2 bundle, with both schemas added to the generator's schema list:

• Request (media-buy/list-products-request.json): generates a flat ListProductsRequest. Two fields come out as unreviewed any, which CI's --coverage-max-unreviewed-any 0 rejects: adcp_major_version (other requests already override it to *int) and fields (a $ref to media-buy/product-fields.json).
• Response (media-buy/list-products-response.json): generation stops with ListProductsResponse in media-buy/list-products-response.json oneOf branch 0 must have a title so Go can generate a named variant.

The response puts all ten properties at the top level, with discriminator: {propertyName: "outcome"}. Its two oneOf branches carry no properties of their own beyond the outcome constant; they only change what is required:

The generator treats every top-level oneOf in a response as a union of named variant structs (top_level_union_variant_items), which needs a title on each branch and would give two near-identical structs here.

Proposal

Teach the generator one more shape: a top-level response oneOf whose branches add only required (and not: {required}) on top of top-level properties, plus a discriminator, becomes one flat struct. Outcome is a typed enum, and the per-branch rules go into a Validate() keyed on outcome, so a seller can't send listed without products, or unchanged with them. For the request: adcp_major_version as *int like the other requests, and fields typed from product-fields.json.

The alternative is asking the protocol to title the two branches, so the existing union path works. That gives ListProductsResponseListed and ListProductsResponseUnchanged with the same fields, and buyers switching on a type where one field already tells them.

Two other responses also have a top-level oneOf beside top-level properties and aren't generated today: get_reporting_status (titled branches with nested oneOfs) and list_account_changes (untitled branches that carry properties). The rule above would cover neither as written; I'd keep it narrow to the required-only case.

@bokelley, does the flat struct with Validate() work for you, or would you rather the branches get titles upstream? @sujanchalla0510 and @garvitkaushik-123, as reviewers of #596 and the #536 design, your view on the generator rule is welcome too. With an answer I'll open the pull request, including a round-trip test for both outcomes.