fix: derive capabilities and stop letting unknown firmware fields degrade responses (v1.3.2)

[GhostTypes]

Ships 1.3.2.

Fixes

• has_matl_station is now derived, not copied. The raw hasMatlStation field is AD5X-only — a Creator 5 Pro omits it entirely (verified on pid 41 / firmware 1.9.4) while reporting a fully populated matlStationInfo with four loaded slots. It parsed as None, so consumers gating on it saw no material station on exactly the models that have one. The parser already computed the correct value for its own heuristic and discarded it; that value is now what the field exposes, typed bool rather than bool | None.
• Every inbound response model now allows extra fields. GenericResponse and its children forbade them, so one unrecognized firmware key raised ValidationError and send_product_command returned a bare False — indistinguishable from rejected credentials, which ff-5mp-hass reports to the user as a wrong check code. Nested models (MatlStationInfo, SlotInfo, IndepMatlInfo, FFGcodeToolData) were the half that was easy to miss: a child that rejects a field fails the whole response. Outbound request-parameter models keep extra="forbid", where it catches our own typos.
• /gcodeList no longer discards file metadata on an unknown field, and the names-only fallback now logs what it cost.

Notes

• Relates to ff-5mp-hass#18, which stays open until the reporter confirms against 1.3.2.
• The style: commit is a repo-wide black pass, verified AST-identical and kept separate from the fixes.