feat(robot-server): Wire up global error recovery setting

[SyntaxColoring]

Overview

Closes EXEC-719.

Test Plan and Hands on Testing

• After PATCHing the enabled setting to false, newly-created runs should fail when they encounter a defined error like tipPhysicallyMissing.
• After PATCHing the enabled setting to true, or after DELETEing it (resetting it to the default), newly-created runs should enter error recover

Changelog

• Connect the new PATCH /errorRecovery/settings HTTP API so it actually affects run behavior. This closes EXEC-719.

  • One quirk to my implementation:

    This will not affect preexisting runs, unless you also do PUT /runs/{id}/errorRecoveryPolicy. In effect, PUT /runs/{id}/errorRecoveryPolicy refreshes the run's snapshot of /errorRecovery/settings. This is probably confusing; it would be better if PATCH /errorRecovery/settings immediately affected the preexisting run, or if PUT /runs/{id}/errorRecoveryPolicy did not have that refresh effect.

    I don't think this matters in practice because this button will be disabled or inaccessible in our UIs while there's an active run.

Also fix a couple of nearby, unticketed bugs:

• If a client gave us an empty error recovery policy, we were no-opping. Instead, we want to overwrite the current policy with the new empty one.
• The logic in error_recovery_mapping.py was unintentionally enabling error recovery on OT-2 robots if the policy was specific enough. We want it to always be disabled on OT-2s.

Review requests

None in particular.

Risk assessment

Medium: this area needs manual testing.

[sfoster1]

Nice, looks good to me