…#16439)

# Overview

Addresses a long-standing TODO to separate out the pipette movement
conflict and deck-placement conflict code since they are completely
exclusive of each other and don't need to be in the same file.

## Changelog

- moved all pipette movement conflict checking code to
`pipette_movement_conflict.py`

## Risk assessment

None. Refactor only

fixes RQA-3277

<!--
Thanks for taking the time to open a Pull Request (PR)! Please make sure
you've read the "Opening Pull Requests" section of our Contributing
Guide:


https://github.com/Opentrons/opentrons/blob/edge/CONTRIBUTING.md#opening-pull-requests

GitHub provides robust markdown to format your PR. Links, diagrams,
pictures, and videos along with text formatting make it possible to
create a rich and informative PR. For more information on GitHub
markdown, see:


https://docs.github.com/en/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax

To ensure your code is reviewed quickly and thoroughly, please fill out
the sections below to the best of your ability!
-->

# Overview

<!--
Describe your PR at a high level. State acceptance criteria and how this
PR fits into other work. Link issues, PRs, and other relevant resources.
-->

I noticed that the label text next to the toggle button no longer
displays on the Magnetic Module step form. This PR aims to fix that and
update the form to better match the
[design](https://www.figma.com/design/WbkiUyU8VhtKz0JSuIFA45/Feature%3A-Protocol-Designer-Phase-1?node-id=5536-13337&node-type=canvas&t=F8BuTfbRtt7v67rR-0).

## Test Plan and Hands on Testing

<!--
Describe your testing of the PR. Emphasize testing not reflected in the
code. Attach protocols, logs, screenshots and any other assets that
support your testing.
-->
- Create an OT-2 protocol and add a magnetic module GEN1 or GEN2
- Go to the Protocol Steps tab and add a step for Magnet

## Changelog

<!--
List changes introduced by this PR considering future developers and the
end user. Give careful thought and clear documentation to breaking
changes.
-->
- Added an optional boolean `isLabel` prop in
`ToggleExpandStepFormField` to handle displaying label text next to the
toggle button when needed
- Changed `magnetAction.label `from "Magnet action" to "Magnet state" in
`form.json`
- Remove Box component with borderBottom in `ToolBox` to get rid of
double grey separation lines
- Used `getInitialDeckSetup` and `getModulesOnDeckByType` to get the
slot location info for displaying the icon

## Review requests

<!--
- What do you need from reviewers to feel confident this PR is ready to
merge?
- Ask questions.
-->

## Risk assessment

<!--
- Indicate the level of attention this PR needs.
- Provide context to guide reviewers.
- Discuss trade-offs, coupling, and side effects.
- Look for the possibility, even if you think it's small, that your
change may affect some other part of the system.
- For instance, changing return tip behavior may also change the
behavior of labware calibration.
- How do your unit tests and on hands on testing mitigate this PR's
risks and the risk of future regressions?
- Especially in high risk PRs, explain how you know your testing is
enough.
-->

---------

Co-authored-by: shiyaochen <[email protected]>

Works towards RSQ-161

When we want a well set relevant to a specific pipette's interaction with a specific labware, we use a helper, getWellSetForMultichannel. This works great, but it doesn't have the ability to return relevant wells given a nozzle layout. So for example, if the pipette has a nozzle layout of "column" on a 96 channel, and the well of interest is A2, all 96-wells are returned.

This PR adds support for all current nozzle layouts, which are generally utilized in the context of partial tip configs.

In nozzle configurations which do not naturally incorporate the entire row/column (this is only the 8-channel column config with <8 nozzles, currently), return thewellName and the number of relevant wells "lower" than that well name. Ex, if B1 is the wellName and the active nozzle count is 4, return B1-E1.

If less wells are available than the activeNozzleCount, return fewer wells.

…ads (#16397)

<!--
Thanks for taking the time to open a Pull Request (PR)! Please make sure
you've read the "Opening Pull Requests" section of our Contributing
Guide:


https://github.com/Opentrons/opentrons/blob/edge/CONTRIBUTING.md#opening-pull-requests

GitHub provides robust markdown to format your PR. Links, diagrams,
pictures, and videos along with text formatting make it possible to
create a rich and informative PR. For more information on GitHub
markdown, see:


https://docs.github.com/en/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax

To ensure your code is reviewed quickly and thoroughly, please fill out
the sections below to the best of your ability!
-->

# Overview

Counts Gripper Actions with `opentrons_tough_pcr_auto_sealing_lid` and
increased tracking with Plate Reader

## Test Plan and Hands on Testing

Ran scripts and checked results

## Changelog

Added function to count number of times
opentrons_tough_pcr_auto_sealing_lid lid is picked up by gripper
Added functionality to record each byonoy plate read and specify read
type and wavelength
Error handling for google sheets interaction.

## Review requests

<!--
- What do you need from reviewers to feel confident this PR is ready to
merge?
- Ask questions.
-->

## Risk assessment

<!--
- Indicate the level of attention this PR needs.
- Provide context to guide reviewers.
- Discuss trade-offs, coupling, and side effects.
- Look for the possibility, even if you think it's small, that your
change may affect some other part of the system.
- For instance, changing return tip behavior may also change the
behavior of labware calibration.
- How do your unit tests and on hands on testing mitigate this PR's
risks and the risk of future regressions?
- Especially in high risk PRs, explain how you know your testing is
enough.
-->

# Overview

This PR introduces the first version of an Opentrons liquid class
schema. Single liquid class definitions will adhere to this schema and
be keyed by pipette and tip type.

Closes AUTH-832

## Test Plan and Hands on Testing

- Look through schema and ensure it adheres to our finalized liquid
class testing matrix. Any feedback on schema structure/style is
appreciated.
- Try out some test data in a JSON validator. I created a base fixture
that passes schema validation. We can modify that for testing.

## Changelog

- create liquid class schema v1
- add fixture

## Review requests

See test plan. Should we leave keys for `patternProperties` pipette and
tip type less restrictive strings? Perhaps any `safeString` rather than
following more stringent regex?

## Risk assessment

low

`PipetteState` and `TipState` were both storing the length of the pipette's currently-attached tip. I think that duplication was accidental. The `TipState` one was only used in one place, so this deletes that in favor of the `PipetteState` one.

…id seal labware (#16345)

Covers PLAT-356, PLAT-264, PLAT-540

Publicizes "opentrons_tough_pcr_auto_sealing_lid" labware. Implements multilabware stacks, new labware allowedRole "lid" for labware, alongside "lidOffsets" subcategory of the gripper offsets.

…anguage setting to app config (#16393)

adds a config app language value to desktop/ODD and initializes i18n
language to the stored app language config value. detects the user's
system language in desktop app-shell and transmits to renderer via
IPC/redux. adds a system language config value.

closes PLAT-504, PLAT-497

…hem in app (#16448)

fix PLAT-476, PLAT-477, PLAT-478, PLAT-479, PLAT-481, PLAT-484, PLAT-486

…th fixed trash (#16451)

* fix(components): fix disabled button style in PD

* feat(components): add two icons for PD

* fix(protocol-designer): remove # from version text

…r module. (#16453)

…lect pipette screen (#16464)

* fix(protocol-designer): remove opentrons phrase from checkboxes in select pipette screen

* refactor(protocol-designer): export metadata as a component

#16461)

#16465)

* fix(protocol-designer): fix snackbar display issue in select a pipette

…EditInstrumentsModal (#16438)

* fix(protocol-designer): fix pipette type button display condition in EditInstrumentsModal

#16467)

Closes RQA-3286

Adds "fixed trash" as a predefined drop tip location for OT-2s during drop tip wizard.

Closes EXEC-760

The loadPipette command is important for executing commands associated with a specific pipette, but it also resets internal state, which can leads to bugs like the ones in the linked ticket. If the pipette has been loaded earlier (ie, during error recovery, synonymous with fixit command flows), we should not load the pipette. We still load the pipette during maintenance runs (drop tip wizard when not in error recovery).

# Overview

Wrap second `ProtocolOverview` column once minimum page width is hit

Closes AUTH-716

…mponent (#16432)

* fix(protocol-designer): update Step part design and export it as a component

Closes RSQ-161

This PR adds partial tip support during Error Recovery flows, specifically for tip pick-up during overpressure error recovery. After talks with design, users will be unable to select wells themselves if using a partial tip layout, since this helps prevents unexpected pickups. There are some special-cased copy updates, too.

Closes EXEC-765

Adds an option for toggling error recovery. If ER mode is disabled, the run fails instead of entering recovery mode.

This PR implements the liquid class schema as shared data Pydantic models for usage in other parts of the codebase.

…col command text (#16478)

After #16451, it seemed like a good idea to do an audit of our O(n) getLabwareDefinitionsFromCommands util to see if we could improve performance elsewhere in the app. Turns out, pretty much every place that it's used has room for improvement (mainly in the case handled by this PR and in LPC flows).

One such place is within each protocol command text. When we display a list of protocol command texts, for every protocol step associated with a labwareId, we iterate over the entirety of protocol analysis. This commits acts as a half-measure: hoist out the util far enough to reduce most of the negative performance implications.

…ator (#16476)

In our `DeckConfigurator` component, there is a leaky equality check for
selected cutout ID with configured thermocycler cutout. The situation
arises when a thermocycler is configured in cutout A1 and the selected
cutout ID is B1, or vice versa. These point to the thermocycler being
configured in the same physical location, so we should check whether
both selected and configured cutout IDs are included in thermocycler
cutouts ([cutoutA1, cutoutB1]).

…non-Optional (#16481)

closes AUTH-881

…16472)

* feat(protocol-designer): introduce react-lottie for animations in PD

…16487)

Closes EXEC-723

This commit closes out the gripper flows by adding the expected gripper behavior given the door status. These affordances include proper jaw release while the door is open, ensuring the door is closed before z-homing the gripper, implicitly z-homing the gripper if the door is already closed after releasing labware.

There's some minor refactoring here as well. Copy for gripper flows was recently updated, so some views are refactored to handle different copy depending on the selectedRecoveryOption.

The major challenge here is thinking through all the permutations of gripper/door state behavior. One of the trickier aspects is implicitly executing fixit commands, since most commands up to this point are directly tied to a CTA. We have a semi-pattern for this useInitialPipette. If we do more implicit fixit command behavior, it will probably be worth spending the time to think through how to elucidate this implicit behavior a bit better, since the control flow is dense.

…16482)

closes AUTH-819

…16491)

…er lid as labware (#16489)

fix PLAT-483, PLAT-525, PLAT-526, PLAT-547, RQA-3310

Closes RQA-3287

After the semi-recent drop tip wizard cleanup, in which the fixit DT flows were more decoupled from the setup DT flow logic, the wizard eagerly closes before ensuring the maintenance run was actually deleted. This can put drop tip wizard in a weird state if launched too quickly after exiting, as seen in the ticket with the 500 POST request to the maintenance_runs endpoint. To fix this, let's just ensure we don't close the wizard until the request settles.

This commit also fixes a weird bug. If you access drop tip wizard from the Device Details page and a pipette unrenders during drop tip wizard, it sometimes toggles a lot because we pass a generic drop tip toggle, and several different things within DT wiz call this toggle. By specifying enableDTWiz and disableDTWiz, this problem no longer occurs.

)

Closes RQA-3311

This PR creates and implements the new `StepSummary` component to be
shown under the deck map in `ProtocolSteps`. The component produces
different messages based on all step types and formats them with inline
tags and various StyledText styles.

We developed a utility function `orderRuntimeParameterRangeOptions` to
order choice-type parameters in the `ParametersTable` and
`ProtocolDetails` components. However, the util incorrectly assumed that
the RTP choice array passed to the utility was of length 2 when it could
also be of length 1. This PR filters the array of any length rather than
explicitly indexing its second element to fix the bug.

closes AUTH-807

…nit failure on the Flex. (#16483)

Closes EXEC-722

This PR wires up the FE implementation of the "Tip Drop Failed" Error Recovery flow.

This flow is straightforward. The only real refactor is that the copy for recovery options is now special-cased, so instead of "Retry step", it's, for example, "Retry dropping tip".

Note that the feature is not fully implemented until EXEC-764 closes.

…opTipInPlace` commands (#16485)

Closes RQA-3273

RESC tickets identify that a common problem for OT-2 users undergoing calibration flows is that there is not any error messaging when something goes wrong. More specifically, the app never bubbles up errors received from the server, effectively black-holing them.

This commit adds an error details modal modeled after one used in drop tip wizard, implementing it for all OT-2 calibration flows. Because stale errors will display after relaunching calibration flows after an error, we clear all robotApi requests every time we launch a calibration flow. Doing so should not impact the app, since the selectors utilizing these requests were unused until now! Note: clearing just the one error request is insufficient, since it's possible for a user to receive several of the same errored responses, which results in the same stale error problem on the next calibration flow.

re AUTH-805

<!--
Thanks for taking the time to open a Pull Request (PR)! Please make sure
you've read the "Opening Pull Requests" section of our Contributing
Guide:


https://github.com/Opentrons/opentrons/blob/edge/CONTRIBUTING.md#opening-pull-requests

GitHub provides robust markdown to format your PR. Links, diagrams,
pictures, and videos along with text formatting make it possible to
create a rich and informative PR. For more information on GitHub
markdown, see:


https://docs.github.com/en/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax

To ensure your code is reviewed quickly and thoroughly, please fill out
the sections below to the best of your ability!
-->

# Overview

<!--
Describe your PR at a high level. State acceptance criteria and how this
PR fits into other work. Link issues, PRs, and other relevant resources.
-->

Update the rename step feature to allow users to rename a step and add
step notes when they click the rename button on step forms.

## Test Plan and Hands on Testing

<!--
Describe your testing of the PR. Emphasize testing not reflected in the
code. Attach protocols, logs, screenshots and any other assets that
support your testing.
-->

- Go to Protocol steps and add a step
- Click the rename button and confirm that a modal appears
- Save the new step name and step notes
- Verify that the step name is renamed (the step details will be added
below the command summary as the next task).
- Ensure it matches the
[design](https://www.figma.com/design/WbkiUyU8VhtKz0JSuIFA45/Feature%3A-Protocol-Designer-Phase-1?node-id=11219-264190&t=1OIUHns25vPqdMDK-4)


## Changelog

<!--
List changes introduced by this PR considering future developers and the
end user. Give careful thought and clear documentation to breaking
changes.
-->
- Created a new `RenameStepModal` under the `organisms` directory to
display a modal for users to update the step name and step details
- Added `renameStep()` and `RenameStepAction` interface in
`labware-ingred/actions/actions.ts` to handle changes
- Updated `StepFormToolbox` to handle rename button click
- Added a unit test for `RenameStepModal`
## Review requests

<!--
- What do you need from reviewers to feel confident this PR is ready to
merge?
- Ask questions.
-->
- I used `CHANGE_FORM_INPUT` as the type for the `RenameStepAction`
interface, taking it from the old PD `ChangeFormInputAction` to handle
`stepName` and `stepDetails` updates. Am I supposed to use this, or
should I create a new type, add it to
`labware-ingred/actions/actions.ts`, and use that instead?

## Risk assessment

<!--
- Indicate the level of attention this PR needs.
- Provide context to guide reviewers.
- Discuss trade-offs, coupling, and side effects.
- Look for the possibility, even if you think it's small, that your
change may affect some other part of the system.
- For instance, changing return tip behavior may also change the
behavior of labware calibration.
- How do your unit tests and on hands on testing mitigate this PR's
risks and the risk of future regressions?
- Especially in high risk PRs, explain how you know your testing is
enough.
-->

---------

Co-authored-by: shiyaochen <[email protected]>
Co-authored-by: shiyaochen <[email protected]>

…dit transfer (#16488)

closes AUTH-870, partially addresses AUTH-926

…nks (#16480)

Fixes https://opentrons.atlassian.net/browse/RESC-339

…it (#16509)

closes AUTH-930 AUTH-926

Partially closes EXEC-776

As the "ignore error and skip/retry" routing no longer applies only to one recovery option, it's worth revisiting the way we structure routing/copy. More importantly, we probably should avoid sending any sort of "ignore all errors" policy updates to the server until the user exits error recovery, because sending policy changes earlier could provide unexpected behavior if the user selects the "ignore all option" but then clicks "go back".

If the PUT request for the policy updates fail, route the user to our "recovery failed" modal and let the user select a different (or same) option.

AUTH-835, AUTH-836

# Overview

Adds `LiquidClass` class and `ProtocolContext.define_liquid_class()` to
PAPI. Also adds an `allowLiquidClasses` feature flag that will need to
be set to True in order to use the new API method.

## Changelog

- added `LiquidClass` dataclass to PAPI
- added `ProtocolContext.define_liquid_class` to define a liquid class
in the protocol
- added `allowLiquidClasses` internal feature flag

Some small schema changes:
- changed `liquidName` -> `liquidClassName` and made it a `safestring`
- added a `displayName`
- changed `tipType` -> tiprack

Misc shared data changes:
- added `liquid_classes.load_definition()`
- added validation tests for liquid class definitions

Closes EXEC-777

#16510 appears to have fixed most of the inPlace issues we had seen back in 8.0, and it has (hopefully) greatly simplified the additional support the app needs to provide to get inPlace variations of aspirate/dispense working.

This commit just wires up those commands to the appropriate flows.

implements the system language modal that displays on first boot of the
desktop app or when the language of the computer running the desktop app
changes.

closes PLAT-536

* fix(protocol-designer): add Eppendorf to removeOpentronsPhrases

* fix(labware-library): fix labware-library css issue

<!--
Thanks for taking the time to open a Pull Request (PR)! Please make sure
you've read the "Opening Pull Requests" section of our Contributing
Guide:


https://github.com/Opentrons/opentrons/blob/edge/CONTRIBUTING.md#opening-pull-requests

GitHub provides robust markdown to format your PR. Links, diagrams,
pictures, and videos along with text formatting make it possible to
create a rich and informative PR. For more information on GitHub
markdown, see:


https://docs.github.com/en/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax

To ensure your code is reviewed quickly and thoroughly, please fill out
the sections below to the best of your ability!
-->

# Overview

<!--
Describe your PR at a high level. State acceptance criteria and how this
PR fits into other work. Link issues, PRs, and other relevant resources.
-->

This PR enables static meniscus-relative aspirate and dispense via the
Protocol API. To enable this, WellVolumeOffset has been added to
WellLocation. This is a volume of liquid to account for when executing
commands with an origin of WellOrigin.MENISCUS. Specifying
`operationVolume` results in this class acting as a sentinel and should
be used when volume can be determined from the command parameters, for
example commanding Aspirate. A volume should be specified when it cannot
be determined from the command parameters, for example commanding
MoveToWell prior to AspirateInPlace.

## Test Plan and Hands on Testing

<!--
Describe your testing of the PR. Emphasize testing not reflected in the
code. Attach protocols, logs, screenshots and any other assets that
support your testing.
-->

Successfully tested the following protocol on a robot multiple times in
a row. Aspiration from meniscus was not tested due to not-yet-available
InnerWellGeometry:
```
from opentrons.protocol_api import ProtocolContext
metadata = {"protocolName": "Test LLD"}
requirements = {"robotType": "Flex", "apiLevel":"2.21"}


def run(ctx: ProtocolContext) -> None:
    """Run."""
    tiprack = ctx.load_labware(f"opentrons_flex_96_tiprack_1000uL", "A3")
    source = ctx.load_labware("nest_12_reservoir_15ml", "C2")
    sink = ctx.load_labware("nest_96_wellplate_100ul_pcr_full_skirt", "D2")
    pipette = ctx.load_instrument("flex_1channel_1000", "left", liquid_presence_detection = True)

    pipette.pick_up_tip(tiprack)
    pipette.measure_liquid_height(sink["A1"])
    pipette.aspirate(10, source["A1"])
    pipette.dispense(10, sink["A1"].meniscus(-2))
    pipette.return_tip()
```

## Changelog

<!--
List changes introduced by this PR considering future developers and the
end user. Give careful thought and clear documentation to breaking
changes.
-->

## Review requests

<!--
- What do you need from reviewers to feel confident this PR is ready to
merge?
- Ask questions.
-->

## Risk assessment

<!--
- Indicate the level of attention this PR needs.
- Provide context to guide reviewers.
- Discuss trade-offs, coupling, and side effects.
- Look for the possibility, even if you think it's small, that your
change may affect some other part of the system.
- For instance, changing return tip behavior may also change the
behavior of labware calibration.
- How do your unit tests and on hands on testing mitigate this PR's
risks and the risk of future regressions?
- Especially in high risk PRs, explain how you know your testing is
enough.
-->

…#16516)

Update [winston](https://www.npmjs.com/package/winston/v/3.15.0) which
is what we use for logging on the node side to the most recent version
(3.15) so that we can use `logger.child()`, which lets you override
logger metadata without having to create another logger instance.

The reason to do this is that each full winston logger instance hangs
event listeners off its shared transports
(winstonjs/winston#1334) which results in
annoying node warning messages about memory leaks that aren't real and
are just based on "did you add more than a magic number of listeners to
this event". With the child logs, nothing adds the events, and we don't
get the warnings.

Also, get rid of the file logging to `/app/ODD/logs/error.log` and
`/app/ODD/logs/combined.log`, because we're already sending everything
to journald via the console and [using that to provide the logs via
http](https://github.com/Opentrons/opentrons/blob/edge/robot-server/robot_server/service/legacy/routers/logs.py#L16)
so it's just extra storage wear and space usage that we don't actually
need.

## testing
- [x] do the logs still go

The edge overnight analyses snapshot test is failing. This PR was opened
to alert us to the failure.

Co-authored-by: y3rsh <[email protected]>

## Overview

Heal edge on missed snapshot change due to #16525

Closes EXEC-776

This commit is a hodgepodge of small refactors to update error recovery to match designs (and fix small things that bother me and probably no one else).

b98064d - Updates the drop tip wizard copy to match designs
e8ff83f - If you look at "go back" and "continue" buttons, they aren't actually aligned. I think I borked this recently.
041305e - The deck map in ER slightly pushes down the "continue" button so it's not perfectly aligned with other error recovery "continue" buttons. This fixes that.
beb4184 - If you click "view error details" on the desktop app and adjust the size of your app, eventually the error details modal doesn't align with error recovery. Let's fix this by giving InterventionModal the same padding styling as the basic modal, which it should probably have regardless.

* fix(protocol-designer): enable color picker's alpha value

* fix(protocol-designer): fix remove settings icon button

* fix(protocol-designer): fix create button clickable area issue

…16530)

* feat(components): add new icons for PD tip-position browser

Updates PD privacy settings copy according to latest legal
recommendations. Adds links within copy to direct to privacy policy and
opentrons EULA.

Closes AUTH-902

Closes EXEC-739

Closes EXEC-773


Now that we have a definitive locations for general app utils, all general utilities should now be imported through places like local-resources and not from the internals of component directories. One of the biggest culprits of violating this rule is Commands. We use a lot of these utilities elsewhere.

This commit serves as a general refactor for display name utils, which entails:

* Migrating them to local-resources
* Tightening the interfaces. More specifically, instead of passing all of protocolAnalysis, pass only what we need.
* The above has the added benefit of highlighting potential problem parameters, ie, commands. I actually caught a couple more unnecessary cases of iterating through protocolAnalysis, so this refactor reduces TC by O(2n) in some spots.
* The above also enforces stricter typing - there are actually a couple spots that could cause whitescreens on older protocols, because we weren't properly typechecking protocolAnalysis before attempting to iterate through modules or labware when it could in fact be an object and not an array. I guess in practice, this probably doesn't happen much, since I've personally never seen any tickets about this.

Closes RQA-3287

In #16490, I made the disable/enable drop tip wizard states more explicit. However, I also removed the logic to toggle() the wizard if it abruptly closes, which sometimes happens if the pipette card unrenders. This just adds the unrender logic back and makes it more explicit: if the flow does close abruptly, it's important we do clean up the maintenance run, too.

Covers PLAT-380, PLAT-468
Allows plate reader to save CSV files through a new FileProvider in protocol engine tool, created and passed in
through robot-server.

…6512)

This PR updates when StepSummaries show and updates copy to reflect
final decisions. The intended behavior is to only show StepSummary when
a step is hovered or selected, but not when the step form is open.
Hovered StepSummaries take precedence over those of selected steps. I
also add an optional second element to StepSummary that will display the
step's notes if they exists.

Closes AUTH-886

#16518)

Partially closes EXEC-557

Raise a defined over pressure error for prepare for aspirate command.

… item (#16538)

* fix(protocol-designer): add setHovered functions to clear unnecessary item

…ery (#16549)

Closes EXEC-557

Flex robots are capable of updating their own software from the Internet
or from USB sticks containing update files. This functionality is
handled by the ODD's node side in `app-shell-odd`. It was implemented
early in the flex development life cycle before we'd gotten a strong
understanding of how everything would work, and was therefore a little
scattershot and not really conformant to the way we now think about and
structure our code. It also had some unexpected behaviors and was
generally a little buggy.

This PR refactors `app-shell-odd`'s system update mechanisms, ideally
fixing said bugs.

## non-goals
### changing the frontend or the redux interaction patterns
this was already a pretty big pr, so I didn't touch these. They probably
should be touched, though; sourcing updates from web or from usb is a
different thing from sourcing updates from web or from the user's file
browser, which is what the UI side and the redux messages are designed
to implement, and the concepts don't map terribly well.

The redux message flow and semantics should not change in this PR, and
this PR doesn't touch any app code

### changing the precedence or user-visible functionality of system
updates
We still have this idea that
- Updates should be presented when an available update is different than
the current system version
- Updates from USB sticks have higher precedence than updates from the
internet, even if the update from the internet has a higher version than
the update from the USB stick
- If multiple updates from sources of the same precedence are available
(i.e., a USB stick with multiple update files is connected) then the
update with the highest version takes precedence

Changing this would require changing the frontend to have more than a
"press a button to start an available update" type of flow, and require
changing the redux messages.

## goals
### make the code easier to reason about
The code was split sort of weirdly between a single ts file and a module
of ts files; code to handle USB updates was scattered around the code to
handle internet updates; it was generally a tough assignment to figure
out what would happen when user actions are taken or redux messages are
sent. Make it easier to understand
### make the code more robust
The code didn't really uniformly handle errors or handle errors in the
same way in multiple places; this is pretty much guaranteed because the
code didn't really have tests.

## changes
- move all the system update code into `system-update`
- separate the code strongly by layer. the layer that handles the redux
messages is in `system-update/handler.ts`, and it imports functions from
lower levels in the `from-usb` and `from-web` modules.
- separate the code strongly by source. all code dealing with updates
from the web is in the `system-updates/from-web` moduels; the code
dealing with updates from usb is in `system-updates/from-usb`. Each
module presents a closure with a well-defined interface that the handler
can use.
- remove global mutable state in favor of closed-over mutable state for
better testability
- add tests, for everything (this is where the size of the diff is from)

## review requests
- this is a pr that is mostly motivated by readability and robustness,
so opinions on how readable and robust the code is are very welcome and
needed
- is the behavior correct from the description above?

## reviewing
This ended up being a pretty big PR, sorry! I think a good way to
approach looking at is to structure into the mostly-separate changes,
which only affect each other implicitly:
- the new cancellation mechanics in HTTP as its own thing
- the action distribution changes in `main`
- the `app.getPath()` changes in `main` and in `config`
- the mechanics of `system-update/handler` first, then the two update
providers underneath; the logic here is separated into "conveying the
status of updates" in `handler.ts` and "getting updates" in the
providers
- the usb device sensing changes, which handle mass storage devices that
are like `/dev/sda` but mounted at `/media/VOLUMENAME-sda` and fix
excessive timeouts in the recursive enumeration

## testing
this needs to be tested on a flex (conveniently, the OT-2 doesn't run
this code). things that should be tested are
- [x] when the robot is connected to the internet on an update channel
that has an available update that is higher than the current robot
version, does the system download, present, and apply the update
- [x] when the robot is connected to the internet on an update channel
that has an available update that is lower than or the same as the
current robot version, does the system download but not present the
update
- [x] when the robot is connected to the internet on an update channel
that has an available update, then disconnected after downloading the
available update, does the system present and apply the update
- [x] when the robot is disconnected from the internet while downloading
an available update, does the system not present the update
- [x] when you change the update channel, does the presented update get
properly cleared and re-queried, including
- [x] changing from a channel with an update to a channel with a
different update
- [x] changing from a channel with an update to a channel without an
update
- [x] changing from a channel without an update to a channel with an
update
- [x] when you plug in a usb stick with an update, it gets detected,
presented, and applied
   - [x] including when an update is available from the internet
- [x] including when the internet update is of a higher version than the
usb update
   - [x] including when there are multiple updates on the usb stick
- [x] including when the update on the usb stick is a lower version than
the current version of the robot

Closes RQA-3060

* fix(protocol-designer): fix TC module rendering for OT-2

* feat(protocol-designer): remove multi modules feature flag

# Overview

This PR adds the Prompt Review component that will be consumed by the
Create Protocol flow in the new AI Client.


![image](https://github.com/user-attachments/assets/afdf6be4-b675-495c-9f4f-2fdc79a23eaf)

## Test Plan and Hands on Testing

- Basic scenarios manually tested
- Unit tests

## Changelog

- Add Opentrons AI Client Prompt Review component

## Review requests

- Validate if this approach for creating components fits the project
structure and best practices

## Risk assessment

- No risk