halui: clear the MDI flag in the same pass that restores the mode

[grandixximo]

Fixes #4604.

When a halui MDI command finishes, modify_hal_pins() restores the Task mode that was active before it and then clears halui_sent_mdi. The two steps tested emcStatus->status == DONE separately. The restore goes through emcCommandSend(), which refreshes emcStatus while waiting for the echo, so if Task echoes the restore while still reporting EXEC, the restore fires but the clear is skipped.

With the flag left set, the next sendMdiCommand() does not record the current mode and keeps the previous halui_old_mode. In the #4604 log that is what happened: MDI command 1 ran from AUTO, the test then switched to MDI and ran command 2, and when command 2 finished halui restored AUTO (the SET_MODE with serial +13). The test then timed out waiting for MDI.

A stuck flag does not have to leave extra commands in the log: sendAuto() is a no-op when the mode is already AUTO, and a DONE seen at that point clears the flag silently. The failure needs Task to report EXEC from the restore until the next MDI command is triggered, which is what the 161 ms Task stall in the CI log provides. That also explains why the test passes under plain CPU load.

The fix takes the DONE decision once, before the restore, and uses it for both steps.

Testing: I reproduced this deterministically with a local, not-for-merge patch that makes Task report EXEC for a set time after each EMC_TASK_SET_MODE:

• window 0.3 s from serial 10 on: master fails 8/8 with the exact halui test mdi race? #4604 signature and the same command sequence (+10 SET_MODE 2, +11 SET_MODE 3, +12 PLAN_EXECUTE g0 y2, +13 SET_MODE 2); with the fix 5/5 pass.
• window 0.15 s on every mode change: master fails 5/5 at the first restore with "timeout waiting for task mode to get to 2 (it's 1)", the other signature this test has shown in CI; with the fix 8/8 pass (0.15 s and 0.3 s).
• tests/halui passes without the injection.