First, you should not worry about your in-memory transactions, the transactions send from specific node are backed on the disk. If you restart the node, they will refill the mempool (but you don't have to do this right now).
Second, you may resend these transactions to other nodes using resendwallettransactions API. But this will not resolve mining problem, it will just make them available there. Also, they are not stored on disk by those nodes until confirmed in block.
Third, it looks like mining stopped because you have more than 3 miners in the chain - and these miners are not what you see in the output of listpermissions. For the address to have mining permission, its grant should be confirmed in block. But listpermissions shows the state including unconfirmed transactions, which is obviously misleading - we will think how to improve this in the next version.
It looks like you have at least 4 miners in the chain:
1K73Tko1w9ZVPaSL5L5RHFEBnbNVWTHB5c8owZ and 1WmQoWUM5GjErTH1KnjQjDSThGEFapx6GMqTGQ are OK, but they cannot mine because of diversity.
But 1b2Sn4sfWwXJammXTqoAkAkB5ssQfPBHdov3zR and probably some other node we cannot currently see in the output of APIs (but it is not 1UgYYerpfmaV5R1sMpWSci6ymP4HD25G2FPHAs) are the miners which should mine the next block, but they are probably down.
(if you examine carefully the mempool of the first node, you are likely to find there two "revoke" transactions for 1b2Sn4sfWwXJammXTqoAkAkB5ssQfPBHdov3zR and another address and one "grant" for 1UgYYerpfmaV5R1sMpWSci6ymP4HD25G2FPHAs - you don't have to do this now)
And finally, why the first node tries to mine the block when it can't (and you see error messages in the log) - this is the bug we already fixed in the latest version. But it is not critical bug, you may ignore it, so you should not even upgrade MultiChain because of this.
The simplest solution is to bring back (at least temporarily) the node with address 1b2Sn4sfWwXJammXTqoAkAkB5ssQfPBHdov3zR or that miner with unknown address. If it is possible, after you bring up this node, make sure it is connected to other nodes and then call resendwallettransactions from these nodes. Then wait until mining is restarted and getmempoolinfo output shows 0. After that, you may stop that node(s).
If this doesn't work for you for some reason (you don't have private key for 1b2Sn4sfWwXJammXTqoAkAkB5ssQfPBHdov3zR or you don't remember exactly what was that "other" address), please let us know and we'll look for another solution. In this case I have to know who are the admins, i.e. we need the output of
listpermissions admin * true
