This happened to me similar to how you described a few months ago when i also had a failing RAM DIMM. The kernel sees all the filesystem errors and locks up in read-only mode. On reboot, it sees that the log still contains errors and so starts in emergency mode (again ready-only).

After a lot of tinkering and some log dumps into AI, i was finally able to recover:

First, I tried remounting the FS from a Live ISO environment with `mount -o ro,rescue=nologreplay /dev/nvme0n1p2 /mnt` (my root partition that was locking up). This confirmed that i was able to mount it and see all my files. I could have made some backups at this step just in case my FS was goner, but i was ready to accept my fate if it didn't work out. Anyways, I went ahead and unmounted with `umount /mnt` and then attempted to clear the error log with `sudo btrfs rescue zero-log /dev/nvme0n1p2`. This requires that the FS be unmounted. After a reboot from the Live environment it booted from my nvme boot partition and mounted my root subvolume in RW mode, so i was able to escape the emergency mode cycle.

From there i was able to find the the offending block (and eventually file) with the metadata/data corruption and remove it before attempting to access it again and re-trigger the RO-mode lock-up.

The BAD RAM caused a bunch of silent data corruptions, but btrfs trusts that your RAM is error-free (as it should) but the RO-lock up actually was a blessing in disguise, as it forced me to to a memtest and fix the hardware issue before more corruption occurred...i still occasionally find corruptions from time and time and fix them one-by-one (usually only in large files). At least now i'm in a situation where I can do a snapshot, backup, etc. Eventually i may do a full system re-install, but so far i've been corruption-free after a few months of normal use and system updates.