Catalog: add rfc9449-multiple-dpop-proof-headers-must-be-rejected (§4.3 #1)

[RobertoIskandarani]

The dpop_multi_header scenario row (PR #2) supplies an error code for the multi-header rejection, but nothing in the catalog asserts the rejection itself — RFC 9449 §4.3 #1 ("there is not more than one DPoP HTTP request header field") is MUST-level and currently untested.

Proposed case:

• id: rfc9449-multiple-dpop-proof-headers-must-be-rejected
• surface: sdk-verifier.dpop.inbound
• outcome: reject, error_category: invalid_dpop_proof
• Include the RFC 9110 §5.3 variant where an intermediary joins repeated header fields into one comma-separated value — §4.3 Catalog: add the RFC 9449 multi-header invalid_dpop_proof carve-out #2 ("a single and well-formed JWT") rejects it too, and a naive header-count implementation passes it.

[RobertoIskandarani]

Holding the merge on this one until the SDK repositories pin the catalog by SHA.

Today every SDK clones this catalog at its default branch in CI. The alignment
guard asserts in both directions — every catalog case has a registered mapping,
and every mapping exists in the catalog — so introducing a new case id lands
in all of them at once, and each SDK goes red until it registers coverage. Scenario
rows added to an existing case (as in #2) do not have this property; a new id does.

None of the SDK repositories reads a pinned ref yet, so merging this now would turn
CI red across all of them simultaneously, on PRs that touch none of this.

The pinning work is in flight. Once each SDK reads a pinned SHA, it adopts a new
case deliberately, together with the matching coverage, and this can merge without
a coordinated red.

No objection to the case itself — the §4.3 #1 carve-out is right and the id is
well-formed. This is purely about sequencing.