* [x]  This PR contains no AI generated code **(but the docs were AI-generated)**

Ahh, we can't accept any AI generated content. not just code. So this will need to be reworked.

I was researching key rotation because I am moving my instance from a relatively not trusted environment (playground in public cloud) into a relatively trusted environment. I was surprised to find no documentation or recommendation about rotation in the docs, especially given that the keys are stored not in HSMs.

Whenever we discuss something like this, we need to do so with a risk/threat model.

In the keycloak case, this appears to be used to cause token expiration to occur. Specifically refresh tokens in this case, as reading between the lines they say " If a user was inactive in the period between the new keys being added and the old keys being removed, that user will have to re-authenticate."

We have separate methods to ensure that refresh tokens have an expiry that doesn't rely on private-key rotation. So this doesn't apply.

The zitadel docs don't describe why rotation should be undertaken.

If an admin is rotating keys because they think they might be compromised, then they should be revoking the keys instead, not rotating them. Just rotating keys on a schedule, seems like a very specific need.

So I think while we should document how to rotate and revoke keys, we shouldn't be prescribing a schedule for key rotation to occur. Things like that always have to be done with some kind of goal in mind.

Anyway, we do want to support HSMs in future, the private key handling internal to Kanidm would actually allow it. we just don't have any HSM's available to do the development work against today!