Why would you need to read through the paper to see if it applies? Are you deployed in settings where attackers can physically flip bits or not? That question, the only one that matters, is posed essentially in the abstract of the paper.
Yup, Olm could conceivably be deployed in settings where attackers could physically flip bits, but we're not aware of anyone doing so yet (all current usage is on non-embedded devices where the hassle of bit flipping would be enormous).
Assuming I've correctly skimmed the paper, it looks like it relies on your Ed25519 impl incorrectly reusing the same 'r' value when signing messages - and then deliberately flipping bits whilst it does so, in order to gradually recover the private key. Our usage of Ed25519 doesn't reuse 'r' values, so I think Olm is okay.
The article acknowledges RFC6979, which is the standard way to produce a deterministic r that doesn't have this problem intrinsically. It also refs RFC8032, which has EdDSA in it (both variants).
The fault attack acts after that deterministic generation, so tha fact that Olm doesn't reuse r values explicitly doesn't matter. You're not _erroneously_ reusing r: the attack involves you trying to sign the same message twice, with a fault occurring on the second signing.
When signing the same message, all EdDSA implementations are supposed to reuse the same `r`, as per RFC 8032, and thus to produce the same signature under the same key. For smartphone and instant messaging, I wouldn't be worried about fault attacks, there are probably easier ways around it.
