Save (or clear) the property outline, and with it the geocoded map label and the point the map opens on.

A dedicated endpoint rather than attributes on updateProperty, because it is the single place three rules are enforced:

• A typed area is never overwritten by a drawn one. area_source: "drawn" recomputes area_ha from the ring; area_source: "typed" saves the ring and leaves area_ha exactly as it is. A request that names no source keeps the property's own, so omitting the field can never clobber a typed number; a property that has never had one gets drawn.
• Geometry is repaired before it is measured. Rings are validated (at least 4 positions, closed, finite, latitude within ±90 and longitude within ±180), repaired with ST_MakeValid, wound counter-clockwise and stored as a MultiPolygon — so a self-crossing ring cannot report a plausible-but-wrong hectare figure. The geometry read back may therefore be reordered or split into parts.
• A saved ring always leaves the map a point to open on. When the property has no centroid and the request names none, one is derived from the ring. An existing centroid is never moved.

Area is computed by PostGIS as ST_Area(geography) in hectares.

Provenance. boundary_source (traced | grid | gps | imported) is the client's claim about how the ring was captured and travels with it; boundary_captured_by is stamped server-side from the acting user and is never accepted from the request. Both are cleared with the ring. A property boundary writes no diary row — records attach to paddocks and mobs, not to a property — and it is never distance-guarded the way a paddock ring is: the property's own point may have been geocoded to the town, and the ring is what corrects it. Requires edit rights on the owner.

{
  "data": {
    "type": "property",
    "blocks": [
      {
        "name": "Racecourse block",
        "hull": {
          "type": "Polygon"
        }
      }
    ]
  },
  "_meta": {
    "onboarding": {
      "skill": "pg-onboarding@1"
    }
  }
}