PlannedError has no Headers and no media-type election now that ErrorCase is a response

[fuad-daoud]

Found in review of #438 (Wahbeh-Mohammad).

#422 gave ir.ErrorCase a name, headers and all media types, so an error response now lowers structurally exactly as a success one. docs/emitter-design.md was updated on the IR side but not on the plan side, and the two now contradict each other in one example.

At emitter-design.md (the 429 worked example) the IR line reads Payload:{Contents:[…]}, Headers:[Retry-After], while the plan line directly below still reads:

PlannedError{ Conditions:{429}, Type:RateLimited, Fault:"client", Retryable:true, Throttling:true }

described as "declared IR facts, carried as such".

PlannedError (§3.1) is {Conditions, Type *ir.TypeRef, Fault, Retryable, Throttling}. Two gaps follow:

1. No Headers field. Retry-After is the motivating example in ir.ErrorCase is second-class beside ir.Response: no Name, no Headers, no per-media-type payload #422 and it is a declared IR fact with nowhere to sit in the plan.
2. Payload.Contents is plural, Type is singular. The 429 in per-status-errors.yaml carries two media types, so a single Type implies an election the document never names. The only election machinery in the document is success-side — PrimaryContent with its json > form > multipart > binary order, described at §3.2 as "the one legitimate home for the collapse". Two emitters reading the same 429 could pick different media types for the exception body and neither would be wrong by this document.

Suggested fix: add Headers []ir.Property to PlannedError (or carry the *ir.ErrorCase the way PrimaryResponse carries the *ir.Response), state beside PrimaryContent that PlannedError.Type is elected from ErrorCase.Payload.Contents by the same negotiation, and update the worked example's plan line to match the IR line above it.

Deferred from #438: it is emitter-design work — a new plan field plus an election rule — rather than a correction to what that PR changed.