Filter property search by any indexed attribute (v5.5.0)

Added

Property search filters now cover every indexed attribute by its dotted path: 144 canonical fields, for example address.postcode, building.construction.year, epc.rating.current.band, floodRisk.riskLevel and roomDetails.beds, plus every existing short alias, on POST /v1/property/query and the query clause of POST /v1/property/aggregate. The whitelist is generated from the live index mapping: keyword and boolean fields take term comparators, numeric and date fields add range comparators, and nested blocks such as listings and saleHistory are handled transparently. GET /v1/property/attributes marks each attribute filterable and reports the real filter target.
marketStatus.forSale and marketStatus.forRent, the names used in responses and the attribute catalogue, now work directly as filter fields, equivalent to the existing saleListingStatus and rentalListingStatus aliases.

Unknown filter fields and comparator mismatches on POST /v1/property/query return a descriptive 400 with code invalid_query_condition naming the problem and pointing at the attribute catalogue. Filtering on a permission-gated field returns an explicit 403 with code permission_denied rather than leaking which properties match.

Property search documents polygon and point coordinates in GeoJSON [longitude, latitude] order, and POST /v1/property/query returns a clear 400 with code invalid_coordinates for malformed area geometry, explaining that polygon rings need at least three distinct points and must be closed. Well-formed requests, including existing GeoJSON-order integrations, are unchanged, and locationId is always included whatever you request.
listingType and listingStatus filters use exact-match term semantics.