fix(app): fix blocking LPC on the flex when the protocol does not involve a tip pick up

[mjhuff]

Closes RQA-4159

Overview

useLPCDisabledReason is responsible for blocking LPC due to LPC-external reasons. Some of these reasons are OT-2/Flex specific, and depend on a robotName, which is an optional prop. This optional prop was not passed to the hook for the ODD LPC entry point, which defaults the hook to treating Flexes as OT-2s on the ODD.

To fix (see d25ee1b), we just pass the robotName prop. While I did consider marking the prop as non-optional, which seems like the correct thing to do, the blast radius seems a little too great given that we render quite different copy depending on whether this name is supplied or not, and I don't think where we are in the release cycle lends itself to making a larger change.

Upon further investigation (30481e9), it appears that the desktop app was missing some calibration/module specific blocking reasons. The original prop names lend themselves to thinking they only apply to the ODD, but I don't see why this is the case after reviewing how the props are used. My guess is there used to be some existing discrepancies in how desktop vs. ODD setup used to occur that are no longer relevant. I think keeping the two apps consistent in their disabled reasons warrants this change, but I'm open to discussion on this point.

42c9609 is just a simple refactor: relocate a util since it's not ODD specific anymore.

Current Behavior

Screen.Recording.2025-04-30.at.2.31.08.PM.mov

Fixed Behavior

Screen.Recording.2025-04-30.at.2.30.31.PM.mov

Test Plan and Hands on Testing

• Audited all our usages of useLPCDisabledReason, ensuring that correct props are passed in all places.

Changelog

• Fixed LPC on the ODD sometimes being disabled for OT-2 reasons.

Review requests

• How do we feel about 30481e9? Does this change seem reasonable given where we are in the QA cycle? Easy to revert if we need to, but I personally think we want this.

Risk assessment

lowish

[sfoster1]

that is weird and complicated, thanks for fixing. reason #999999 to refactor protocol setup

[SyntaxColoring]

Wow, not at all what I thought that bug would be. Thanks for untangling that.