fix(domain-instances): OSM IDs are flat per-type spaces; adapter constructs prefix from coordinates

Closes Codex P2 on PR #41 (now merged).

# The error

§2.6 said:

  > "OSM IDs are *already* prefix-structured
  > (`country/region/city/street/house`), so the adapter is doing
  > identity-*extraction*, not identity-construction"

That's wrong on two axes:

  1. OSM IDs are NOT hierarchical. Per the OSM data model
     (https://wiki.openstreetmap.org/wiki/Data_model), Node, Way,
     and Relation each have their own per-element-type flat numeric
     ID space. `Node 100`, `Way 100`, and `Relation 100` are
     unrelated; IDs carry no spatial information.

  2. The "country/region/city/street/house" hierarchy I cited is
     what Nominatim CONSTRUCTS from geocoding queries — it's an
     *output* of geocoding, not a property of OSM IDs. Relying on
     identity-extraction from raw OSM IDs would produce non-local
     or colliding NiblePath keys (the Codex P2's specific concern).

# The fix

Rewrite the §2.6 lead paragraph to correctly describe:

  - OSM elements use per-element-type flat numeric ID spaces (with
    Wikipedia-link to the OSM data model spec for citation).
  - The adapter does identity *construction*, not extraction:
      * Computes the Cesium TMS quadkey FROM the element's
        coordinates (for Node/Way with geometry).
      * For Relations without coordinates, derives from the
        centroid of members OR from an admin_level boundary walk.
      * Prepends the quadkey to the per-type OSM ID, yielding
        `osm/<quadkey>/<type>/<id>` as the NiblePath form.
  - Pins the architectural distinction: "The quadkey IS the spatial
    frame; the per-type ID is the leaf inside it."

# Internal consistency

  - The "Spatial prefix-locality" bullet's example
    `osm/<quadkey>/way/123` matches the corrected lead's form
    `osm/<quadkey>/<type>/<id>`. Unchanged.
  - The verbatim §6 callout ("Marienplatz is_in Munich in sub-
    microsecond") still holds: Marienplatz IS routed via
    `osm/<munich-quadkey>/way/<id>`, and `is_in Munich` IS a
    quadkey-prefix-containment check. The mechanism is unchanged;
    only the lead's origin-story was wrong.
  - The §3 capability matrix row "Spatial prefix routing (Cesium
    TMS quadkey via NiblePath)" already correctly named quadkey
    (not OSM ID) as the prefix source. Unchanged.
  - The Q2 coordination outcome (Cesium TMS quadkey as NiblePath)
    is unchanged — this fix tightens the prose that explains WHY
    the outcome was correct.

# Verification

  cargo check --workspace --all-targets    -> clean (docs-only)
  PII abort-guard (word-boundary)           -> CLEAN

# Note

The error was framing-grade, not architecture-grade. The runtime
session's lance-graph PR #473 §2 already correctly specified
"Cesium TMS quadkey as NiblePath prefix" (Q2 outcome) — the
mistake was in my §2.6 lead claiming the prefix came from the
OSM ID structure rather than from the coordinate-derived quadkey.
The corrected text now matches the Q2 outcome's design intent
exactly.

https://claude.ai/code/session_01PBTGaPCSnnt6u3pjXpbLwY

Author: claude

docs/DOMAIN-INSTANCES.md

@@ -125,13 +125,22 @@ inner auth AND durable outer audit, and ships exactly that separation.
 
 ### 2.6 Geospatial / OSM — geographic calibration
 
-**What OSM proves: geography doesn't break the IR.** OSM IDs are
-*already* prefix-structured (`country/region/city/street/house`), so
-the adapter is doing identity-*extraction*, not identity-construction
-— a much smaller surface than typical. Three OSM Classes (`Node`,
-`Way`, `Relation`) lift via the queued `ogar-from-osm-pbf` adapter
+**What OSM proves: geography doesn't break the IR.** OSM elements use
+**per-element-type flat numeric ID spaces** ([OSM data model][osm-dm]
+— `Node 100`, `Way 100`, and `Relation 100` are unrelated; IDs are
+not hierarchical and carry no spatial information on their own). The
+adapter therefore does identity *construction*, not extraction: it
+computes the Cesium TMS quadkey **from the element's coordinates**
+(or, for `Relation`s without coordinates, from the centroid of its
+members or from an `admin_level`-boundary walk) and prepends it to
+the per-type OSM ID, yielding the `NiblePath` form
+`osm/<quadkey>/<type>/<id>`. The quadkey IS the spatial frame; the
+per-type ID is the leaf inside it. Three OSM Classes (`Node`, `Way`,
+`Relation`) lift via the queued `ogar-from-osm-pbf` adapter
 (`docs/RDF-OWL-ALIGNMENT.md §10` Phase 2c). Exercises:
 
+[osm-dm]: https://wiki.openstreetmap.org/wiki/Data_model
+
 - **Spatial prefix-locality** — Cesium TMS quadkey as `NiblePath`
   prefix, per Q2 coordination outcome locked in `lance-graph` PR #473
   §2. HHTL trie routes `osm/<quadkey>/way/123` byte-identically to