STARPIPChannel.request_x_pos: send C0 RX via left_x_arm

[BioCam]

STARPIPChannel.request_x_pos was sending C0 RA pn=<channel> with fmt="ra#####" — three independent bugs that together made the method unable to return a real X-arm position.

Problems

1. Wrong command class. C0 RA reads non-volatile EEPROM constants (calibration values set during service); it doesn't query the live X-arm encoder. Live X position is C0 RX.
2. Invalid field. pn is not a valid C0 RA field — RA accepts only id and ra=<param>.
   The firmware silently ignores pn. Verified on hardware: with no ra=, RA echoes the most-recently-queried EEPROM parameter (after ra=kg returns kg328; after ra=kf returns kf3682) — so the broken implementation would have leaked an arbitrary, order-dependent EEPROM constant rather than a position.
3. Format mismatch. fmt="ra#####" cannot parse any real C0 RA reply, since responses always lead with the queried parameter name (e.g. kg<value>), never literal ra.
   Net effect: ValueError on every call.

Fix

Delegate to the existing STARXArm.request_position() (which sends C0 RX — verified on hardware to return the live X-arm carriage X).
All PIP channels share the (left) X-arm carriage, so the value is the same regardless of self.index.
Matches PLR:main's request_x_pos_channel_n behaviour.

async def request_x_pos(self) -> float:
    assert self.driver.left_x_arm is not None, "left_x_arm not set; call driver.setup() first"
    return await self.driver.left_x_arm.request_position()

A # TODO comment at the call site flags that this assumes a single rigid X-arm — needs revisiting for half-arm and Fluid Motion STAR (issue #822).

[rickwierenga]

thanks!