fix(app): fix errant GET /run/:runId requests

[mjhuff]

Overview

When viewing the Devices tab on the desktop app, there are a lot of GET requests to /runs/null. These errant requests are generated by two places:

useRunStatuses

The complex enabled logic has bit us in the past here - in this case, the custom enabled condition overrides the default condition not to fetch if there is no runId, creating the errant fetch. Prior to notifications, it was important to selectively enable this hook to prevent polling unnecessarily. However, telemetry indicates that pretty much everyone uses notifications, and this hook uses notifications, so for the sake of keeping things simple, let's just remove this logic. Worst case scenario, it's not terrible to poll here if MQTT is blocked.

useNotifyRunQuery

A manual refetch() does not use the underlying enabled conditional logic of useRunQuery. There are two ways to solve it, either the way in this PR, or do extend useRunQuery to return a manual refetch function that wraps the custom, lower-level enabled logic.

For simplicity, I've chosen path 1, but I do think it would be worth revisiting this if we add more notification hooks with "always fetch only in specific circumstances" type logic.

Test Plan and Hands on Testing

• On the desktop app, navigated to the Devices tab and noted that healthy reachable robots without active runs no longer make requests to runs/:runId.

Changelog

• There are no longer errant network requests to /runs/runId when there is no active run.

Risk assessment

low - this doesn't touch networking in any potentially strange way.

[sfoster1]

Easy once we work through the logic