That is somewhat of a completely different topic... 
The distributed actor work by itself does not introduce any "unwinding" facilities or other mechanisms similar to "panics". This is not the focus of the proposals under discussion right now.
It very much remains an area I'd personally, as server developer, be interested in improving in the future, but we don't have specifics to share here. You can see me describing some of the ideas for "soft faults" all the way back in 2019 here: [stdlib] Cleanup callback for fatal Swift errors - #4 by ktoso and it also is aligned with our interest of improving the backtrace experience and of course the ability to strongly isolate state which distributed actors bring to the table. So maybe there's potential here in the future, but right now we're not looking actively into this.
It is true that distributed actors provide a very strong isolation mechanism, that could be used to build upon and utilize strong guaranteed isolation to provide some ways for fault tolerance.
Today Swift does not offer "panics" or unwind mechanisms which would be necessary to implement this in-process; but if you wanted to achieve resilience by a process transparently spawning child processees in which "child (distributed) actors" a spawned and communicated with transparently from the main process... then those child actors could crash the entire process independently and without impact on others. So that is one way one could use distributed actors -- to isolate crashes thanks to process boundaries. I had prototypes of this approach, so it is absolutely doable, but remains to be seen if interesting to the community