openapi: share one implementation of the inferred-marker list #1071

Problem

Provenance.Inferred holds one string, and a node more than one heuristic reaches lists their names, comma-separated, with no name repeated (ir-design §12, "Promoting a vendor extension into the field it is the only spelling for", rule 3). TypeRef.Inferred (#1065) follows the same convention. Three functions in the OpenAPI compiler each implement the list:

• lowering.markInferred (compilers/openapi/internal/lowering/promotion.go) adds one name to a provenance unless it is listed.
• operation.joinInferred (compilers/openapi/internal/operation/streaming.go) joins the non-empty names it is given, without checking for repeats.
• merge.joinMarker (compilers/openapi/internal/merge/merge.go, from feat!: mark inferred nullability and warn on 3.0 $ref siblings #1065) adds one name to a list unless it is empty or listed, for intersectNull.

They agree today because each meets only distinct names, but each restates the convention, so a change to it (another separator, an order rule) has three places to land.

Direction

A proposal. The convention is the IR's, and ir is the one package all three reach, since merge may import neither lowering nor operation (internal/archtest). One helper there, such as ir.ListInferred(list string, names ...string) string, appending each non-empty name not yet listed, would replace all three. operation.joinInferred would gain the repeat check it lacks, which changes nothing while its inputs are distinct.

Out of scope

Whether Provenance.Inferred and TypeRef.Inferred should become []string. That is an IR shape change with its own version bump, and the string is the documented form.

Related: #1065

Priority: P4, housekeeping. It changes no lowering, validation, IR or emit-contract behaviour (git grep -n 'func markInferred\|func joinInferred\|func joinMarker' → three definitions, morphic @42a8d640).