EtherCAT drive communication - reliability improvements

Two related problems, seen at a customer site and reproduced on the bench:

1. The controller could get stuck in an endless retry loop bringing a drive up. It gave the drive only 2 seconds to complete its transition to Safe-Op; a drive still finishing its own internal startup work reports "busy," not "failed," but the controller treated busy as failed, restarted the connection, and reset the drive's work each time - so a slow drive could never finish. The drive is now given up to 30 seconds, while a drive that actually rejects the transition still fails immediately. This was the endless-loop fix.

2. Separately, after a drive recovered from a fault (cable pulled, power blip), the first reconnect attempt failed with a burst of confusing error messages. Cause: the drive sends an unsolicited status announcement our software did not understand, which knocked the conversation out of step - like two people each answering the other's previous question. This recovered on its own but wasted time and filled the log with noise. The software now recognizes these announcements, double-checks every answer matches its question, and if the conversation still gets out of step, gives up on that attempt within seconds and starts fresh.

Also improved: the log now tells a readable story - which step failed, why, and what the drive said, one line each - instead of dozens of raw error codes.

Result: Pulling the drive cable and plugging it back in now recovers to full operation in about 5 seconds with a short, readable log. Verified on the bench against the failure mode the customer site is seeing.