OT-2 (legacy): fix _current_channel_position, and add move_channel_to

[miikee]

_current_channel_position calls ot_api.lh.save_position, which ot_api
does not define. Every caller therefore raises, so move_channel_x,
move_channel_y and move_channel_z on the OT-2 backend cannot work at all
today: they always fail with RuntimeError: Failed to query current pipette position.

It now enqueues savePosition itself and polls the command the way ot_api's
own command wrapper does. The poll awaits rather than sleeping, so a robot that
never answers does not hold the event loop for the whole 30s budget.

With the read working, move_channel_to moves a channel to an absolute
position and holds whichever axes are left out. Chaining the per-axis calls was
the only way to reach an arbitrary point before, and each of those descends
separately, so a three-axis move could clip labware between the steps. This
lifts to the traversal height and travels once. get_channel_position exposes
the read.

Not verified on an OT-2. I do not have one. The savePosition command and
its response shape are the same ones a Flex uses, where they are hardware
verified, and the new tests fake the robot at its command queue so they pin the
params a real robot would receive.

Known gap I did not want to fold in silently: move_channel_x/y/z still
duplicate the same three lines rather than delegating to move_channel_to.
Delegating would change what those three do on the wire (a coordinated move
instead of a single-axis one), which is a behaviour change I would rather
propose separately than smuggle into a fix. Happy to do it here if you would
prefer.

Draft, and independent of my PreciseFlex PRs. A second OT-2 PR follows this
one, bounding every request and taking it off the event loop.

[miikee]

Superseded by #1240, which carries this commit plus the request-bounding work that builds on it. Verified: this branch's tip is an ancestor of #1240's head, so nothing is dropped.