I agree, I would definitely not make any changes during business operations or without being physically present in case things go south.
Stepping back, use of untagged VLAN 1 is not advised. Short of addressing that, some port maintenance/cleanup might help. VLAN-unaware devices on trunked ports (which VLAN should they be on?) and manual link negotiation on port 15 (unless that's intentional) are two examples that jump out.
It'd be much easier to troubleshoot if you updated your port descriptions with more consistent naming, so that it's clear which ports have WAPs connected, which ports have other VLAN-un/aware devices connected, which ports have nothing connected, etc. (Physically connecting all devices in adjacent physical groupings, like grouping the physical ports on the front of the switch itself by what's connected at the other end, is even better.)
Finally, going out on a limb here—but I would be very unsurprised if your issue actually has less to do with the switch and more to do with the Cloud Key/WAPs (i.e. controller/adopted devices)... however their interconnectivity might relate to switch configuration. The next piece of the intermittently-losing-WAP/s puzzle is more likely to come from the Ubiquiti side of things than the L2 switching side of things. That you're able to observe negotiated link speed changes simply confirms that something is happening to the link itself, but that doesn't necessarily point to the switch or the connected host (especially when the connected host is a device being 'controlled' by a third device on a different port).
What we can be pretty certain of however is it being astronomically unlikely that this switch is failing at a hardware level.
