Migration guide from multi-cluster - #51316

docs/guides/high-availability/multi-cluster-v2/migrate-from-v1-to-v2.adoc:172

• This decommissions Infinispan, fencing, and monitoring before the updated v2 deployment has started or passed verification, so a bad image or CR leaves no readily usable v1 rollback path. Keep the v1 infrastructure until after the deployment and verification steps complete, then perform this cleanup.

. Remove the {jdgserver_name} deployment.

docs/guides/high-availability/multi-cluster-v2/migrate-from-v1-to-v2.adoc:196

• The v1 procedure also creates xsite-token-secret for the remote site's service-account token, but this cleanup omits it and leaves that credential secret behind. Delete it along with the other cross-site secrets.

kubectl --namespace keycloak delete secret remote-store-secret
kubectl --namespace keycloak delete secret ispn-xsite-sa-token
kubectl --namespace keycloak delete secret xsite-keystore-secret
kubectl --namespace keycloak delete secret xsite-truststore-secret

docs/guides/high-availability/multi-cluster-v2/migrate-from-v1-to-v2.adoc:100

• Pending email-verification and password-reset links are self-contained action tokens, so they are not lost here; what is lost is the revocation metadata for already-consumed tokens, which can allow those tokens to be accepted again until expiry. Please describe that security impact separately from the OAuth authorization codes that are actually stored in this cache and become invalid.

This issue also appears in the following locations of the same file:

• line 172
• line 193

Action tokens in the {jdgserver_name} cache::
Email verification links, password reset tokens, and OAuth codes that were stored in {jdgserver_name} are lost.
Users with pending email verifications or password resets need to request new links.