fix(app): Fix "retry new tips" during Error Recovery overpressure flow

[mjhuff]

Closes RQA-2989

Overview

Drop tip wizard's tip detection logic comprised of checking the sensors and checking the protocol analysis. Recently, we dropped the sensor detection and now rely purely on protocol analysis. Doing so exposed a bug: based on the way command fetching works out of post-run drop tip wizard, we can't always tell during a run in progress if tips are attached without writing extensive special-case logic for error recovery or performing questionably large network requests for command data, so when error recovery tries to do recovery flows involving drop tip wizard, it doesn't know which pipette we care about.

A reasonable alternative is something we should have anyway as it creates error boundaries around error recovery:

• If we can't reasonably get the pipette of interest from the protocol analysis, we can almost certainly get it from the failed command (and we get this info via failedPipetteInfo, so we can just use it here).
• If for whatever reason we can't get it from the failed command, we can provide a fallback and just route users around drop tip wizard to select another recovery option or to a later step in the flow (this is really just to prevent whitescreening - realistically, we can always get the pipette of interest from the failedPipetteInfo).

f1bdba2 - After solving the white screen issue, I realized I never pushed the commit in a previous PR that actually made use the pipette's natural id to #15970. Woops. This is necessary for any of the commands to work within error recovery, and I'm including it here, because both these commits are required to make it useable!

Test Plan and Hands on Testing

• Verified fixes work as expected when tested against the ticket linked above.

Changelog

• Users can now drop tips again in error recovery.

Risk assessment

low

[TamarZanzouri]

LGTM!