Except both of the projects you just linked too have CLAs, which they updated on switching to AGPLv3. Both use them as a way to offer dual-licensing, so they can charge companies for an AGPL-exception by selling them a proprietary-licensed version, which then supports the FOSS-development. They both were also only able to change to AGPL because of already existing CLAs. At least in Element's case though, they created a two-way commitment in their CLA:

Now, CLAs come in all shapes and sizes: some good and some bad. It’s critical to understand that our reason for requiring one here is to give us the right to sell AGPL exceptions: not to “do a Hashicorp” and switch to a non-FOSS licence in future. We’ve made this clear in the wording of the CLA (using a similar approach to Signal’s CLA) by committing to distributing contributions as FOSS under an OSI-approved licence – many thanks to those who gave feedback on the original announcement to suggest this. You can find the final CLA wording here, derived from the well-respected Apache Software Foundation CLA.

Here's the specific text from the CLA:

Element shall be entitled to make Your Contribution available under Element's proprietary software licence, provided that Element shall also make Your Contribution available under the terms of an OSl-approved open-source license.

I personally consider that a fairly reasonable term. Especially because they specified an OSI-approved license. Element are always going to be bound to that now. This is like the copyleft of contributor license agreements.