Refactor FieldValue ↔ Components conversion to drop large switch/if-else chains #378

The FieldValue ↔ OpenAPI Components conversion (introduced in #375 / #377) relies on several long switch and if-else chains:

• Sources/MistKit/Models/FieldValues/FieldValue+Components+Scalar.swift
  • makeTypedScalar — switch over Components.Schemas.FieldValueResponse._typePayload
  • makeInferredScalar — if-else chain over valuePayload cases
  • numericValue / stringValue — separate if-else extractors per payload shape
• Sources/MistKit/OpenAPI/Components/Components.Schemas.FieldValueRequest.swift
  • makeScalarRequest — if-else chain over FieldValue cases
  • makeComplexRequest — switch over the remaining FieldValue cases
• Sources/MistKit/Models/Queries/FilterBuilder/FilterBuilder.swift
  • cloudKitListType(for:) / cloudKitComplexListType(for:) — if-else chains keyed on FieldValue cases

These chains are easy to forget to update when a new FieldValue case or a new CloudKit type is added, and the logic for each type is spread across four files instead of being co-located.

Proposal: explore replacing the chains with one of:

1. Protocol-based dispatch — e.g. a FieldValuePayloadConvertible protocol implemented by each value-payload type (or by a per-case wrapper), with the request/response conversion methods living alongside the payload they describe.
2. Static dictionary dispatch — table keyed by _typePayload / a FieldValue.Kind discriminator, mapping each tag to its converter closure.

Either approach keeps the conversion exhaustive at compile time and reduces the duplication across the four files above.

Cross-references: #375, #377.

This is intentionally scoped as a follow-up — #377 fixed the wire-protocol bug without restructuring the surrounding code.