I can confirm the first part but rather unsure about the coincidence with 3.6 as in my observation with org.unifiedpush.example in previous versions not long ago (can´t remember the exact last version) it recognized foundation.e.ntfy in terms of giving a choice when io.heckel.ntfy was installed in parallel (just like Molly still does (!) for instance) - but at some point it did not anymore and that was right after an update of UP-Example. I remember switching versions back and forth to doublecheck and I can say for sure that at this point in time the oddness was on the UP-Example side of things:UP-Example seemingly ignores foundation.e.ntfy but automatically works via io.heckel.ntfy (if present).
(right now I am not willing to kill my working Molly-using-UP-setup by deleting io.heckel.ntfy just to check foundation.e.ntfy)
It´s a pity we have no further information on how foundation.e.ntfy and/or push.murena.com are set up/config´d, we are waiting for a documentation and status-indication for months now after the integrated ntfy was made invisible in device settings in some late 2025 eOS-version.
But for troubleshooting fennec (and testing with UP-Example) it may be worth giving Sunup (a UnifiedPush distributor using Mozilla’s push server) a go (instead of io.heckel.ntfy).
I tried it when I struggled to get Molly-UP into some stable config but did not use it then because it did not allow me to change its default push server for good). From what I recall at that time it worked well - least with UP-Example…
Maybe fennec is happier with a Mozilla-server?
Issues with UP seem hard to troubleshoot as so many different and independent unknowns are involved…