ir: decide whether four no_ir_home operation constructs get real fields

[OmarAlJarrah]

Summary

#272 closed five silent drops in the operation walk. Four of the five are kept as no_ir_home
Unmodeled entries rather than lowered, because the IR has no field for them:

Construct	Kept on	Field the IR would need
Response / encoding header style, explode	Property.Unmodeled	Property.Style, Property.Explode
Parameter allowEmptyValue	Parameter.Unmodeled	HTTPParamBinding.AllowEmptyValue
Error-response content map	ErrorCase.Unmodeled	ErrorCase.MediaType
Path-item servers	Operation.Unmodeled	Operation.Servers

Each is correct as shipped — no_ir_home is exactly the reason for "the IR could hold this and
does not yet", and the entries are routable and reported. This issue is about whether the IR should
close the gaps, which is a design question rather than a bug, and wants the docs/prior-art.md
review that any IR change does.

Why it is worth tracking rather than leaving implicit

Invariant 9 says the IR capability surface is complete from day one, and that shipping OpenAPI
first must never force an IR schema change when a later compiler lands. Three of the four gaps are
not OpenAPI-specific:

• Operation.Servers. §10 already scopes servers by index list at Service and Channel; an
  operation has no such list. AsyncAPI scopes servers per operation natively, and Smithy's
  @endpoint host prefix is the same shape. This one is named in ir-design.md as a gap.
• Header style/explode. PartEncoding holds both for a multipart part, so the vocabulary
  exists in the IR; it is the header carrier that lacks it. Any format with header serialization
  rules reaches the same wall.
• ErrorCase.MediaType. ErrorCase holds one TypeRef and no media type, so an error
  declared only as application/problem+json is indistinguishable from one declared as
  application/json. Smithy's per-error protocol bindings hit this too.

allowEmptyValue is the one that is plausibly OpenAPI-only, and it is also the one whose neighbours
(style, explode, allowReserved, the content-style media type) all already have fields on
HTTPParamBinding — so its absence reads as an oversight in the binding rather than a decision.

Not a request to add four fields

The point is to take the decision deliberately, per-construct, against docs/prior-art.md — some
of these may be better left as Unmodeled than promoted, and that answer should be written down
where the next reader reaches it rather than re-derived. What should not happen is a later compiler
forcing the schema change under time pressure, which is the failure invariant 9 exists to prevent.

Filed while reviewing #272; nothing here blocks it.