This problem has been reproducible on all similar setups where I tried it out.

This example has CAPsMAN manager on router and 2 fixed channel access points as CAP-s with local forwarding.
Let's see, what happens, when radar is detected on one of them
Here we can see radar detection event and subsequent "retry to select channel" event.

Then there is 18 seconds with no log entry, but it is exactly the time, when all CAP interfaces become unbound and remote CAP-s go offline. Then we see CAP-s rejoining manager and all process starts over. As all interfaces go down it seems like we have manager itself reinitializing, which brings all wireless managed by this manager down. This cycle will continue until radar detections end or interface which has radar detections is manually disabled. This means that all wireless managed by this CAPsMAN manager will be constantly going up and down with interval roughly equal to radar detection sequence (60...600 seconds depending on selected country/channel). If we have bigger wireless setup (over 20 or 30 CAP-s) and radar detection sequence of affected interface is 60 seconds, it means that all wireless will be down for almost all the time until manual intervention.

There is no way, that this can be seen as "intended behaviour".

Perfectly normal behaviour. DFS channels will do that.
Here is some material; https://www.youtube.com/watch?v=ZbrbRUAfpac

Of course it is perfectly normal, if affected interface goes down, because it should do that by design.

There is nothing normal about manager itself going down and thereby disabling ALL wireless in the customer network alltogether. How can it be normal, that radar detections on one interface can interfere with functioning of all other interfaces and AP-s? They may not even be at the same location, but now in this case all goes down every time - no matter whether it is dual-band or even single-band 2,4 GHz device which has nothing to do with DFS.

ALL goes down. How can it be normal?

The way i read your first post, your problem wasn’t that obvious to me. I can understand your frustation. Can you post your config with a hide sensitive?

A little bit of "backward logic" lead to usable workaround until this bug is fixed.

If CAP interface has to be configured on fixed DFS channel, then just add its frequency to CAPsMAN channel list (or interface properties) twice.
Now when I tested the configuration at location, where 5580 MHz was always triggering radar detections, all worked as by design - this one fixed-channel interface went to "waiting-for-channel" state for 1800 seconds and all other interfaces were not affected (manager did not crash any more).

Here is the reasoning that lead to this idea - when trying to click "Reselect channel" button when frequency was added once (as by usual configuration), it resulted "fixed channel or no supported channels" error message, but when this same frequency was added twice, interface just did normal channel selection ending up on same channel without error message.

This issue is fixed in the latest RouterOS version in the testing branch - 6.46beta59.
It also will be fixed in the next stable and long term branches.