How does the wallet obtain the nonce for issuing sender-constrained access token?

OID4VCI states that

7.2 The Credential Issuer MAY provide a DPoP nonce in an HTTP header as defined in Section 8.2 of [RFC9449].

8.2 is about obtaining a new nonce, so I suppose one should rather follow clause 8. Authorization Server-Provided Nonce for the initial nonce, that indicates that the nonce is returned in an error response to the token request

On the other hand, HAIP states:

Sender-constrained access token: MUST support DPoP as defined in [RFC9449]. Note that this requires Wallets to be prepared to handle the DPoP-Nonce HTTP response header from the Credential Issuer's Nonce Endpoint, as well as from other applicable endpoints of the Credential Issuer and Authorization Server.

I do not understand why support of RFC9449 requires the wallet to handle something from the nonce endpoint.

It seems to me that some clarification would be beneficial here. Can we clearly state how the wallet obtains the first nonce (from the token request as in RFC9449 or nonce endpoint?) and how the nonce is renewed afterwards?

Start by comparing the cited OID4VCI clause 7.2 and clause 8 with RFC9449 section 8.2, then review the HAIP statement about the Nonce Endpoint. Clarify how the first nonce is obtained and how later renewal works, and update the relevant specification text so the wallet and issuer behavior is unambiguous.