feat(api): allow ungrip gripper labware while door is open

[TamarZanzouri]

Overview

closes EXEC-734.
add ungrip command and allow queuing it and executing it while door is open.

Test Plan and Hands on Testing

1. upload a protocol that will enter ER mode.
2. open door.
3. issue an ungrip command:

{
    "data": {
        "commandType": "unsafe/ungripLabware",
        "intent": "fixit",
        "params": {
        }
    }
}

4. make sure the gripper opens its jaw.

tested with dev server and the command succeeded but still need to test with an actual gripper (@SyntaxColoring thank you Max)

Changelog

1. added an ungrip command unsafe/ungripLabware
2. added logic for queuing while the door is open.
3. added logic for allowing to execute while door is open.

Review requests

1. gripper command makes sense?
2. logic changes make sense?

Risk assessment

medium. added a new command but need to make sure nothing has changed with the door saftey.

[sfoster1]

i know it's a draft, i'm just marking changes so we don't forget to put this in schema 10 once #16401 is merged

[sfoster1]

inline changes.

also is it really the case that we need to care about specifically the queue status for awaiting recovery, and specifically the engine status for AWAITING_RECOVERY_OPEN_DOOR? Can these both query the same thing?

[SyntaxColoring]

Latest commits should address the feedback above.

I did make one change to the logic, to make sure these special ungrip commands can also be queued and run when the engine status is awaiting-recovery-paused, not only when it's awaiting-recovery-blocked-by-open-door. If we're saying they're safe to run while the door is actually open, presumably they're also safe to run if the door has been closed and the closure just hasn't been "logically acknowledged" yet.

[TamarZanzouri]

tested with the app and postman. works as expected!

[sfoster1]

Nice, thanks for changing the name structure!