STARBackend: make iSWAPInformation immutable

[BioCam]

Follow-up to #1055, addressing the frozen=True half of @burnpanck's @dataclass(kw_only=True, frozen=True) suggestion.

iSWAPInformation is constructed in a single expression at every call site (_set_up_iswap inlines all firmware queries as kwargs; chatterbox and tests pass literals) - never built incrementally - and no code reassigns its fields. Declaring it frozen enforces immutability structurally: accidental field writes raise FrozenInstanceError instead of silently corrupting a record that downstream code treats as a single source of truth.

eq=False because two fields are dicts (rotation_drive_predefined_increments, wrist_drive_predefined_increments); the default frozen=True, eq=True would auto-generate a __hash__ that raises TypeError: unhashable type: 'dict' the first time an instance is hashed (latent today, but a trap for future use as a dict key or set member). With eq=False, __eq__ and __hash__ fall back to object's identity-based defaults, which matches how existing call sites and tests use the record (assertIs, never field-by-field equality).

kw_only=True from the same suggestion is deferred: it requires Python 3.10+, and pyproject.toml declares requires-python = ">=3.9" (CI lint and typecheck both run on 3.9).

Behaviour-equivalent.

Part 22 of the "Tame the iSWAP" epic:
https://discuss.pylabrobot.org/t/intro-to-epic-tame-the-iswap/517

[rickwierenga]

there are probably more classes that benefit from this

[BioCam]

Yes, I completely agree, but for Head96Information we need to think a bit more about each piece of information and I recommend aggregating the information for the others first like we did with the iSWAPInformation, identify which parameters might require a helper function based on firmware-specific changes, and then freeze them like this.

i.e. this is just the start which we have high confidence in being ready right now