fix(app): fix routing inconsistencies after a run

[mjhuff]

Closes RQA-2922, RQA-2886, RQA-2944, and RQA-2950

Overview

We were on the right track in #15875 (see this PR for more context) for how to handle the routing issues after completing a run, but it turns out we have to set the caches to empty for BOTH of the endpoints used by useCurrentRoute to get proper behavior, which makes sense in retrospect.

The attached tickets are either directly solved by this PR are solved by this PR in conjunction with #15943.

Test Plan and Hands on Testing

• Verified that after a run, clicking "return to dashboard" on the ODD doesn't do anything unexpected.
• Verified expected behavior for "run again" on the ODD.
• Verified the desktop app/ODD are in sync after getting into states described in the linked tickets.

Changelog

• Fixed routing issues on the ODD.
• Fixed the desktop app thinking the robot is busy when it's not busy.

Risk assessment

low

[SyntaxColoring]

This makes sense conceptually, but should this clearing of the query cache live in useDismissCurrentRunMutation instead? We're already doing stuff there with [host, 'runs'] and [host, 'runs', runId].

[mjhuff]

This makes sense conceptually, but should this clearing of the query cache live in useDismissCurrentRunMutation instead? We're already doing stuff there with [host, 'runs'] and [host, 'runs', runId].

Great Q. Seth and I talked a bit indirectly about this last week. While there's a lot we could and should do with the routing logic (and the ideal fix isn't even clearing caches like we do here - see the TODO a few lines above the fix), the intention now is to keep the blast radius as small as possible. That solution is better for the immediate problem, but it increases the likelihood of introducing issues elsewhere (ex, ProtocolRunHeader). The client-side run context closing logic is complex, and it's quite difficult to reason through all the permutations of that change.

[TamarZanzouri]

Thank you for fixing this!