OAuth 2.0 refresh-token rotation reuse-detection limits

RFC 6749 makes refresh-token rotation optional: an authorization server MAY issue a new refresh token, and the client MUST discard the old value when one arrives. The draft OAuth 2.1 revision recommends rotation with reuse detection for public clients, but as a draft it does not impose a binding requirement on deployed servers.

Because the core framework does not define a required response to replaying a rotated refresh token, the authorization server chooses whether to invalidate only the replayed token or revoke the entire token family. A client cannot infer this policy from the specification, and rotation alone does not bind the access token to the client.

For a public client using PKCE against an authorization server with undocumented reuse handling, what reuse-detection behavior should the client assume when a previous refresh token is replayed?

If the server revokes the whole grant after detecting reuse, should the client interpret a later invalid_grant error as a reason to restart the authorization-code flow instead of retrying the refresh grant?

Should a client that cannot determine the server's reuse-detection policy default to treating any invalid_grant on a rotated token as a full grant revocation?