Thanks for all the replies to this thread. The summary for me is:
1: my particular issue seems NOT to be an LSP sweep and the transaction seems stuck in Mempool due to the high fee situation. The Mutiny UI doesn't help showing 0 balance with no indication of unconfirmed funds, which goes against standard wallet UI, but thanks to @TonyGiorgio kindly looking into the GitHub ticket and demonstrating the transaction is in Mempool the funds appear to be safe assuming they are confirmed eventually.
2: the users who did suffer loss of funds with Mutiny are iOS users and due to a bug in iOS Mutiny PWA broadcasting incorrect state they lost their funds as is by design in the LN. However, funds are apparently being returned by the LSP (Voltage, as posted by @gkrizek and confirmed by @benthecarman ) so this is nothing malicious and is ultimately an inconvenience but not leading to any permenant loss of funds
3: The FC issue appears related to hodl invoices an innovation from Zeus which allows users to receive LN payments even when offline. The issue is that the HTLCs are often sort of in a pending state and that can lead to FCs in the case the sender is offline for an extended period of time. Another cause appears to be Safari browsers clearing state leading to errors (As per @benthecarman). Mitigation steps include not being offline for too long, or not sending to users of hodl invoices. Further mitigations mentioned are an LDK fork from Mutiny which will caused a failure to start node rather than a FC of channel. (As per @benthecarman ) Also there is talk of blacklist to prevent payments to hodl invoices or at least in the future a way to flag them for special treatment to mitigate the issue, such as the ability to cancel pending payments before they expire .(mentioned by @petertodd ) LDK is also working on some means to extend the time interval within which a sender must come online in order to avoid the FC. (As per @benthecarman) there is also talk of adding watchtower support by LDK to make sure FC--of they do occur--are swept in a timely fashion without user needing to be online (as per @benthecarman)
4: As @TonyGiorgio mentions, Mutiny is very clear that Mutiny is a beta project and that issues could happen, and to fund channels with this risk in mind. So people should not expect things to work perfectly at all times in such a fast paced development frontier as LN dev.
5: For me, I had been guilty of being naive not so much with Mutiny, as the team were always upfront on the risks and I never had much in there, but with other wallets like Phoenix I've been too cavalier. What this incident has revealed to me is that the nature of LN means that if you are not running a 24/7 connected LN backend or at least a 24/7 connected watchtower then funds will always be at serious risk in a LN mobile wallet. Not just because of malicious rug/ exit scam risk but because of bugs and things that can and do happen and can lead to loss of funds. Yes, I should have known this. But they polish and exceptional user experience of a wallet like Phoenix sort of hides the risk from users. Going forward I will be trying to keep this lesson in mind and be a lot more wary when using mobile LN wallets without hosting my own backend.