Hi Micah,
It looks as if you have a total of 21 APs in your config, but only 19 APs are adopted.
Use: "show wireless ap configured" and "show adoption offline" to see which ones are missing.
On the primary RFS, You have a license for 18 APs (default 6 + 12 additional), and the default 6 APs on the secondary RFS, making a total of 24 when everything is working properly.
However, the license pool (validity period) appears to be expiring in 1 hour (so it has been 100 days), in which case you will not be able to continue to adopt all 19 APs, and one AP will be dropped, so you are about to experience more problems.
The fact that you mention that you had disabled switch ports because of a broadcast storm problem points back to the fact that the RFSes are connected in duplicate into the network...not ideal, but you'll have to live with it until you can change the topology. I'd also be very careful of the 'cluster handle-stp' that is present in your configuration.
One suggestion would be to restart the second RFS, enable the network ports, if only for a minute or two, just to re-sync the license pool until you can deal with the issue in a more permanent fashion.
You could also look at your switches' spanning tree status on the ports facing the RFSes to ensure none are in blocking or alternate.
I have seen issues with older versions of RFS4000 code (5.4.x specifically) where two cluster members would get into a shouting match with each other and send >10,000 packets/sec to the broadcast address, thus creating what appears to be a broadcast storm.
I would suggest you upgrade to a more recent firmware version, in part to stabilise the cluster and additionally to address the WPA2 KRACK vulnerability (your auditors will be happy... see:
https://extremeportal.force.com/ExtrArticleDetail?n=000018005)
The upgrade should be seamless, but use the RFS4000 LEAN image and load AP firmware for AP6532 and AP6562 into the RFSes once they have been upgraded so that the APs can also be upgraded.