Does the Credential Endpoint follow RFC 9449 §9 (Resource Server-Provided Nonce)?

The spec is explicit that the Credential Issuer acts as an OAuth 2.0 Resource Server:

each Credential Issuer acts as a Resource Server that is protected by an Access Token issued by an Authorization Server, as defined in OAuth 2.0 [RFC6749]. ... All OAuth 2.0 Grant Types and extensions mechanisms can be used with this specification. — §3.2

And §7.2 permits a DPoP nonce at the Nonce Endpoint, deferring to RFC 9449:

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

However the spec says nothing about DPoP nonce behaviour at the Credential Endpoint itself, which is the endpoint actually protected by the access token (§7.1 notes the Nonce Endpoint is explicitly not a protected resource).

Questions:

1. RFC 9449 §9 states resource servers provide the nonce "in the same way that authorization servers do as described in Sections 8 and 8.2", and §8.2 defines supplying a new nonce via a DPoP-Nonce header on an HTTP 200 response. Does that rotation-on-success apply to the Credential Endpoint?
2. More generally: does "All OAuth 2.0 Grant Types and extensions mechanisms can be used" mean a Credential Issuer supporting DPoP is expected to implement the resource-server side of RFC 9449, or is the statement purely permissive?
3. Related to the above: OAuth 2.0 is a single specification with its own conformance surface. Does stating that the Credential Issuer "acts as" a Resource Server make it equivalent to an OAuth 2.0 Resource Server for conformance purposes, or is it intended purely as a role description, leaving each OAuth behaviour to be adopted only where this specification says so explicitly?

The practical impact is on wallet implementations: whether to persist a rotated nonce across credential requests within a flow. Today this is inferred from RFC 9449 rather than stated in this spec, and different implementers are reading it differently.

If the intent is that RFC 9449 applies unchanged, a sentence in §8 pointing to RFC 9449 §9 would settle it — and would also address the request in the last paragraph of #656 for a Credential Endpoint example.

Related: #656, #412, #420

Start by comparing §§7.1, 7.2, and 8 with RFC 9449 §§8, 8.2, and 9, then review related issues #656, #412, and #420. Done means the project records a decided Credential Endpoint nonce and conformance interpretation and updates the relevant specification text or example.