fix(hardware): Fix a bug from the sensor log refactor that broke grip…

…per calibration (#16657)

<!--
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
Since we treated pipettes as a special case for LLD some things got
skipped for the gripper but this fixes it.
<!--
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.
-->

## Test Plan and Hands on Testing
Grippers/pipettes should calibrate succesfully
<!--
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.
-->

## 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.
-->

hardware/opentrons_hardware/hardware_control/tool_sensors.py

@@ -118,7 +118,7 @@ def _fix_pass_step_for_buffer(
             #   will be the same
             duration=float64(abs(distance[movers[0]] / speed[movers[0]])),
             present_nodes=tool_nodes,
-            stop_condition=MoveStopCondition.sensor_report,
+            stop_condition=MoveStopCondition.sync_line,
             sensor_type_pass=sensor_type,
             sensor_id_pass=sensor_id,
             sensor_binding_flags=binding_flags,
@@ -456,6 +456,14 @@ async def capacitive_probe(
     async with AsyncExitStack() as binding_stack:
         for listener in listeners.values():
             await binding_stack.enter_async_context(listener)
+        for sensor in capacitive_sensors.values():
+            await binding_stack.enter_async_context(
+                sensor_driver.bind_output(
+                    can_messenger=messenger,
+                    sensor=sensor,
+                    binding=[SensorOutputBinding.sync],
+                )
+            )
         positions = await runner.run(can_messenger=messenger)
         await finalize_logs(messenger, tool, listeners, capacitive_sensors)