Collapse the zone vocabulary/binding split: zones are floor-level coordinates, unbound goes

[MJohnson459]

A zone is a coordinate in the floor's frame — a fact about the building. The
kitchen does not move. A map revision is an estimate of the same layout
registered into that frame, so re-mapping a floor changes how well the robot
knows where it is and nothing about where the kitchen is; where the two
disagree it is the map that gets aligned. Zones therefore belong to the floor,
in one floors/<floor>/zones.yaml, and neither a map revision nor one robot
owns them.

zone/v0's split imported a premise — "names are shared, coordinates are not,
maps are never shared" — that describes a heterogeneous fleet with one SLAM
frame per platform. Mote's has neither: M4 distributes one canonical revision
to every robot on a floor.

Two commits: the collapse, then the removal of the transition code it had
carried, once a survey showed nothing had ever been written in the split shape.

What changed

• Storage. vocabulary.yaml + binding.yaml collapse into zones.yaml
  (name, note, navigable, x/y/yaw, optional radius/polygon,
  source). The stored counter is revision, not vocabulary_revision: it
  counts a floor's zones, and there is no vocabulary document at floor level to
  number.
• Spec shapes become serialisers. spec/zone.py keeps vocabulary() and
  binding() as views built at the wire from the single record;
  platform_id/frame_id/map_revision are filled in there, never stored.
  split() and merge() are gone.
• unbound goes. A name with no coordinate is not a zone on this floor —
  it is a name nobody has placed, which is what unknown_name says.
  zones.load_floor becomes the one load_zones; mission/v0's
  unresolved_zone carries unknown_name and ambiguous only. Local
  extensions go with it: every zone on the floor is the floor's.
• anchor goes (the addendum). It existed to answer "does this coordinate
  survive a re-map?", and under this model every coordinate does. source
  (save-zone | segment-map | editor) replaces it — what made the zone,
  and nothing about what the coordinate is worth. zone/v0 still requires an
  anchor.method on a binding entry, so zone.bound fills one in from
  source and _ANCHOR_METHOD is the one place that mapping lives.
• No transition code. The split landed in code and migration only ever
  happened on write, so no floor anywhere holds the pair — not this box, not
  mote-01, not the sim bundles, not the fleet server's store. The reader was
  guarding a case that has never occurred, so BINDING_YAML,
  VOCABULARY_YAML, _read_split_pair, zone.source_from_anchor and their
  tests are gone rather than carried. Every docstring and doc now describes the
  one layout that exists.
• Distribution is unchanged in mechanism. A revision carries a copy of the
  floor's zones, promotion publishes an edit, and sites._adopt_zones installs
  the revision's copy over the floor's, keeping zones.<old-rev>.yaml.
• The fleet server's three zone reads are three views of one floor read.
  /v1/maps/<s>/<f>/zones.json keeps its published-map gate (it is served
  beside a basemap); /v1/zones stays ungated and serves the names-only view,
  built from VOCABULARY_KEYS rather than stripped — the safety property
  worth keeping from the split.

mote-01

Its floor was rewritten through the new reader/writer:
vocabulary_revision: 1 became revision: 1, and the fields #609 retired
(kind, display_name, aliases, tags) went — 2195 bytes to 1302. All
seven rooms, their outlines and their navigable flags came through
byte-identical, asserted rather than eyeballed. The original is kept on the
robot as zones.yaml.pre-collapse.

Those seven rooms carried human names in the retired display_name — Living
Room, Bedroom, Bathroom, Kitchen, Guest Room, Office, Hallway — and #609 drops
that field on read rather than promoting it to name, so since that commit the
robot had answered only to room_01..room_07 and goto kitchen failed on it.
Each name is now the zone's name, which is what the record means under
place-names. Done as a one-off migration of one robot's file rather than as a
rule in the reader: a reader that renamed zones could collide two of them
silently.

Verified against the pre-migration file: same seven places, same pose, same
outline (4/4/6/6/5/4/8 corners), same navigable, no retired field left, and
mote_tasks.zones.load_zones resolves every name case-insensitively —
goto kitchen works. The original is on the robot as zones.yaml.pre-collapse.

One consequence worth knowing: promotion is what publishes a floor's zones, so
promoting an older candidate would install its copy over these names. The dev
box's fleet store still holds one such candidate (20260802T203339, carrying
room_01..room_07). Its bytes back an announced digest and must not be
rewritten; the robot's next publish-map supersedes it.

Verification

• 729 passed, 17 skipped across mote_bringup, mote_tasks, mote_fleet,
  run against the worktree sources through the main checkout's env.
• pixi run lint: clean.
• pixi run fleet-ui-check: 47/47, review pane's zones unchanged.
• Every committed zones.yaml (3 sim worlds, 3 sim site bundles, the packaged
  default) round-trips through write/read with identical geometry and no leak
  into the names-only view.
• test_spec_conformance.py against the real augereai-spec checkout:
  10 passed, 1 xfailed.

The xfail

New on test_a_vocabulary_conforms: zone/v0's vocabulary schema still requires
kind, which #609 retired, so Mote's /v1/zones payload does not validate
against it. That divergence predates this work — the test had never
actually run here, because the pixi dev env has no jsonschema and the spec
checkout is not a sibling of a worktree, so it always skipped. Two latent
failures were in it; the other (a stale kind= kwarg that would TypeError)
is fixed, and the geometry-leak assertion was split into its own test so it
still runs. #616 landing the successor revision will fail the marker loudly.

Follow-ups: #629 — the spec should hear why the split was collapsed (a
shared-map fleet is the common case; a binding is per-frame, not per-platform).
#503's lines 25–32 still need rewriting against this model rather than #620's.