Switch toward time-based fallback key rotation

**Suggestion**

The spec currently has this to say about fallback key:

> [Added in v1.2] Fallback keys are similar to one-time keys, but are not consumed once used. If a fallback key has been uploaded, it will be returned by the server when the device has run out of one-time keys and a user tries to claim a key. Fallback keys should be replaced with new fallback keys as soon as possible after they have been used.

I would argue that we should keep fallback key rotation time-based (or rate-limited), rather than rotating the key whenever the homeserver tells us that it was used.

The scenario would be something like:

1. The homeserver hands out all one-time keys.
2. The homeserver starts handing out the fallback key.
3. We come back online and the server tells us that all of our one-time keys have been used up and that the fallback key was used as well.
4. We upload a new set of one-time keys, and a new fallback key if the existing one has expired.

Since at step 4 we necessarily upload new one-time keys, the homeserver will serve those instead. I therefore think it is fine to keep the existing fallback key around until we consider it old enough to rotate.

Rotating the fallback key whenever the server tells us it was used can lead to a situation where someone can cause us to rotate the key too frequently.

For example, if we rotate twice, `B` replaces `A` and `C` replaces `B`, we may no longer have the private part of `A`. Any user that claimed `A` but was delayed in delivering their pre-key message until after we rotated to `C` would then send us a message that we can no longer decrypt.

In other words, the server telling us that a fallback key was *claimed* doesn't necessarily mean that the client has finished using it. There can be an arbitrary delay between claiming the key and delivering the resulting pre-key message.

I'd therefore like to discuss changing the spec to recommend time-based fallback key rotation instead of replacing the key as soon as the server reports that it was used.

Review the fallback-key and one-time-key sections referenced in the issue, along with the current wording on replacing a used fallback key. Assess time-based or rate-limited rotation against delayed pre-key messages and key retention, then update the specification only once the rotation policy and its security implications are agreed.

Written by the indexing model from the issue text.