After KeyPermanentlyInvalidatedException: silent key re-enrollment or forced server re-authentication?

I'm designing credential handling for an Android app that binds its refresh-token encryption key to the Android Keystore with setUserAuthenticationRequired(true) and setInvalidatedByBiometricEnrollment(true). The goal is least-privilege access: no usable credential without fresh user authentication.

The documented behavior creates a fork I can't resolve. When the user enrolls a new biometric or removes the lock screen, the key is permanently destroyed and Cipher.init throws KeyPermanentlyInvalidatedException. At that point the app can either silently generate a new key and re-bind the stored refresh token, or wipe local credentials and force full server re-authentication.

The trade-off: silent re-enrollment is seamless, but the platform provides no signal distinguishing a benign enrollment change from a compromised device, so re-binding could hand a fresh key to an attacker. Forced re-authentication is safer but punishes users for routine lock-screen changes, and I can't tell how common this is across OEM implementations given known inconsistencies in invalidation behavior.

Assume target SDK 30+, TEE-backed keys with StrongBox fallback where available.

1. Which approach is defensible for a mid-sensitivity app, and is there a documented middle ground (e.g., step-up authentication only for re-binding)?
2. Can the server side mitigate this by treating post-invalidation token use as a signal, without the client knowing why the key died?
3. Does the per-use vs validity-window choice in setUserAuthenticationParameters change the risk calculus here?