v0.10.0

The OSM admin endpoint now returns results broadest-first, and — unexpectedly — that made
admin lookups substantially faster.

Changed

• OSM admin results are ordered broadest-first (ascending by level), so a point inside nested
  areas yields the containment hierarchy in reading order — country, state, county, city — rather
  than source-file order:

  United States (2) → Illinois (4) → Cook County (6) → Chicago (8)
  

  This is a storage property, not a query-time sort. OsmAdmin::reorder sorts the items at build
  time (keyed on level, with relation_id breaking ties so regens stay deterministic); the
  lookup cache is built by walking items in order, so lookup is unchanged and the ordering costs
  nothing at runtime. The ordering is documented on the API response type, so it also appears in
  the OpenAPI schema and the TypeScript definitions.

• Admin lookups got faster as a side effect — grouping same-level (similarly-sized) geometries
  together improves scan locality. Measured with the existing criterion benches: full-scan worst
  case −20.5%, assisted sweep −13.5%, random cities −43.0%. This was expected to be a
  small regression, not a win. Verified against the still-unsorted deployed data that the result
  sets are identical (14/14 points) — a pure permutation, not fewer results.

• cargo xtask resort-admins migrates already-generated admin bincodes into the new order in
  ~3 minutes, without the source planet extract (both artifacts derive from the items blob). id
  values shift as a result — they are documented as build-unstable; relationId remains the
  durable identifier.

rtz-core 0.2.1 → 0.2.2 (public HasGeometry::reorder); rtz-build unchanged.

Full Changelog: v0.9.0...v0.10.0