Logical Contradiction between 8.3 and 14.6 on Batch Cardinality

While reviewing the batch credential issuance flow, I may have come across a logical contradiction between Section 8.3 and Section 14.6, regarding the maximum number of credentials that can be issued per request.

Section 8.3 strictly limits the output by stating that "each key provided by the Wallet is used to bind to, at most, one Credential".

However, Section 14.6 contradicts this upper bound by stating that the issuer determines the number of issued credentials "regardless of number of proofs/keys contained in the proofs parameter".

This may cause an ambiguous situation:
if an issuer follows Section 14.6 and returns more credentials than the provided keys, it forces the wallet to either reuse keys across credentials or accept unbound credentials, which directly violates the strict "at most one Credential" rule in Section 8.3.

Start by reading Sections 8.3 and 14.6 in the OpenID4VCI specification and trace how batch credential issuance defines the relationship between proofs, keys, and returned credentials. Determine the intended cardinality rule, then clarify the conflicting normative language and verify that the surrounding batch issuance text remains consistent.