v2.19.9-beta

Fix

After enough one-time pre-keys are consumed, `UploadPreKeysIfNeeded` generates a new signed pre-key (and PQ signed pre-key) and overwrites `Profile.SignedPreKey` / `Profile.PqSignedPreKey` in place. The X3DH responder loop already tried `Profile.PreviousSignedPreKeys`, but the list was never populated — the previous SPK secret was simply dropped, so any X3DH initial the peer built from the bundle they fetched before our rotation could not be decrypted and surfaced as "X3DH key agreement failed."

The same hole existed for the PQ signed pre-key.

Fixes

• UploadPreKeysIfNeeded archives the outgoing classical + PQ signed pre-keys to PreviousSignedPreKeys / PreviousPqSignedPreKeys (new field) before overwriting them, bounded to the last 5 entries.
• HandleX3dhMessage now walks every candidate PQ secret as well — current PQ SPK + archived PQ SPKs — the same way it already walked archived classical SPKs. The OTPK × SPK × PQ-secret triple is tried in a 3-deep loop; first plaintext wins, and only that combination's OTPK / PQ-OTPK is consumed.
• Adds PreviousPqSignedPreKeys to Profile so the PQ archive survives restarts.