Your point regarding liability: as-is systems are unreliable already so much that the manufacturer selling support contracts to firms like mine, so we to improve reliability through humans driving around and fixing&replacing them. The HW manufacturer has insane lucrative contract themselves and so now they need to fix things up so they re-contracting support of their shitty HW down the chain. Can't say more due to NDA. So "broken" state of controllers is already has, so we are not making any new hardware failure points. I did talk to my lawyer, he said my plans are ok. Thank you for your comment!
If there’s no risk of injury/death then the stakes are much lower and indeed since the vendor software itself is already shitty you can’t really make it any worse.
This would effectively let you skip the whole “build a device that emulates an SD card” part.
From there I’d suggest building a Linux image from scratch using Buildroot or Yocto, so you start with a fresh and modern base and don’t have to fight with the SD vendor’s firmware or deal with their vulnerabilities (which might be a liability in your case).
Feel free to get in touch (email in my profile) if you want more guidance.
One thing I would suggest keeping in mind with any kind of interference (regardless of how stable it is and how well it adheres to the SD spec & maintains data integrity) is that if something happens to/with the machinery this controller is handling, your modification can easily be blamed by the vendor, even if your modification isn't actually at fault and it's the vendor's shitty software that's at fault. The risk is double considering it doesn't even seem to be able to manage not corrupting a standard SD card.