fix(models): derive HasMatlStation instead of copying the raw flag (v1.7.1)

[GhostTypes]

Ships 1.7.1. Ports the fix already shipped in flashforge-python-api 1.3.2.

Fixed

• FFMachineInfo.HasMatlStation no longer misses the Material Station on the Creator 5 series. It was a straight copy of the raw hasMatlStation value from /detail, which is an AD5X-only field — a Creator 5 Pro omits it entirely (verified on real hardware, pid 41, firmware 1.9.4) while reporting a fully populated matlStationInfo with four loaded slots. It therefore arrived undefined, and any consumer gating on it saw no station on exactly the models that have one. fromDetail already computed the correct value for its own AD5X heuristic (=== true OR slotCnt > 0 OR non-empty slotInfos) and then discarded it; that derived value is now what the field exposes.

Changed

• HasMatlStation is now a required boolean, not boolean | undefined. A capability has no "unknown" state, and offering one is the mechanism of the bug: firmware omits what does not apply, so an absent field reads as undefined, and undefined reads as "no". FFPrinterDetail.hasMatlStation keeps the untouched firmware value and stays optional, because there the absence is the information. Only fromDetail constructs an FFMachineInfo, so consumers reading the field are unaffected.

Notes

• Neither FlashForgeUI-Electron nor FlashForgeWebUI reads HasMatlStation today (both gate on MatlStationInfo presence), so the regression is inert for them — but both pin ^1.7.0 and should move to 1.7.1 before their next alpha.
• 397 tests passing, including a new case covering a Creator 5 Pro payload that never sends the flag.