STARBackend: resolve installed X-arms into XArmInformation at setup

[BioCam]

The STAR reports its X-arm layout at setup across three replies - arm widths, drive travel ranges, and working envelopes - but nothing fuses them into a single record. The two underlying request methods returned the raw firmware strings, had zero in-tree callers, and left any consumer to re-parse and cross-reference all three sources itself.

This adds the source-of-truth record the X-arm tracking work builds on: one SingleXArmInformation per installed arm, resolved once at setup, mirroring iSWAPInformation (#1055) and Head96Information (#1084).

Resolved parameters

• number_x_arms — count of installed arms: 1 (left rail only, the common STAR) or 2 (both rails).
• position — which rail the arm sits on: left or right.
• width — arm width in mm, from the machine configuration (e.g. 370.0 dual-rail; ≤300 single-rail).
• model — variant derived from width: hamilton_legacy_star_dual_rail_arm (width > 300) or hamilton_legacy_star_single_right_rail_arm (width ≤ 300).
• reference_point — where the tracked X refers to, derived from width: center (dual-rail) or right (single-right-rail).
• x_range — drive travel (min, max) in mm (e.g. dual-rail left (95.0, 1340.4)).
• workspace_range — reachable X workspace (min, max) in mm (e.g. (-323.2, 1517.4)).

Changes

• Adds XArmInformation (left/right, number_x_arms) and SingleXArmInformation (the fields above), both frozen(eq=False) like the other Information records.
• _build_x_arm_information fuses the arm widths, drive travel ranges, and working envelopes into the record at setup, exposed via the x_arm_information property (raises before setup).
• Model and reference point derive from width via _x_arm_model_and_reference.
• request_maximal_ranges_of_x_drives and request_working_envelopes_per_arm (renamed from request_present_wrap_size_of_installed_arms) now parse their replies into typed (min, max) dicts instead of returning the raw string.
• DriveConfiguration.is_present reports whether a drive carries any module, so an absent right arm resolves to None.
• STARChatterboxBackend emits the matching replies and builds the record at setup like the hardware backend.

Behaviour: additive - the two request methods had no in-tree callers, so the rename and return-shape change affect nothing downstream, and x_arm_information is new surface. The single-rail left-drive minimum is fabricated only in the chatterbox (named _DUAL_RAIL_LEFT_X_MIN, 95.0); hardware reads its own value from the drive-range query, and no single-rail dump exists yet to test that path (#822).

Tests: adds TestXArmInformation (the fused record on the default single-left-arm sim, plus _x_arm_model_and_reference by width) and TestXArmRangeQueries (the range and working-envelope parsers against replies observed on real machines); ruff format, ruff check --select I,F, and mypy are clean, and the STAR suite passes.

🤖 Generated with Claude Code