Embedded parent identity vs. parent reference: no consistency invariant #11

Problem

A hierarchical child entity can express its parent's identity in two independent places, with no mechanism tying them together.

Found in `cic-schema-registry`'s `KubernetesNode` (PR #152 review, `theads/thead16.txt`):

1. `binding_surface.addresses[].key_fields`: `backend`/`provider`/`location`/`cluster_id` — the node's address is hierarchically nested under the cluster's address (RESTCONF path: `/clusters/cluster={backend},{provider},{location},{cluster_id}/nodes/node={id}`).
2. `config_surface.cluster_ref`: a `cic-reference` field whose value is the parent cluster's own full `logical_id` (`cic:kubernetes:{backend}:{provider}:{location}:{id}`).

These are validated completely independently. Nothing enforces:

```
dereference(cluster_ref).logical_id == compose(backend, provider, location, cluster_id)
```

A node's embedded address could name one cluster while `cluster_ref` names a different one — both schema-valid, mutually inconsistent.

Why this matters

This is the third occurrence of the same pattern class the corpus keeps surfacing: field-level validation alone is insufficient, some claims can only be checked as a relationship between two positions, not within either position alone.

• `cic-primitives#8` (closed, PR feat: item_choice, collection item discriminated union #9): a collection item's key field couldn't vary by variant — solved with `item_choice`, a structural fix.
• `thead12` (`cic-schema-registry`): a key_field's valid value set is conditional on a sibling field — documented as an accepted, unaddressed language gap (no Contract mechanism exists for "this field's contract depends on that field's value").
• This one: an embedded parent identity and a separate reference to the same parent can silently diverge — no Contract or grammar rule spans two field POSITIONS (one in `binding_surface`, one in `config_surface`) to check they resolve to the same entity.

Scope

Not proposing a fix here — this is a scoping issue, like #6 was for `derivation_chain`. Before any primitive/grammar design: is this worth solving at all (given it's the only known occurrence so far — `cic-schema-registry`'s `Subnet`/`NetworkSpace` pair does NOT have this problem, since `Subnet`'s `binding_surface` doesn't embed the network space's key at all, only a `network_space_ref`), and if so, at what layer:

• a new Contract type that can reference another field's resolved value (something like `type: must` but crossing from `binding_surface` into `config_surface`, which today's `must` expressions with relative paths like `../config_surface/x` might already partially support syntactically, but nothing evaluates cross-position identity/reference equality specifically)
• a dedicated "parent consistency" annotation on the reference field itself
• accept it as a documented, unenforced invariant (like several AdapterContract correspondences already are) and leave it to adapter-level validation

Evidence / references

• `cic-schema-registry` `general/kubernetes/kubernetes-node/kubernetes-node.yaml` — `binding_surface.addresses[].key_fields` (backend/provider/location/cluster_id) vs. `config_surface.cluster_ref`
• `cic-schema-registry` `theads/thead16.txt` — full writeup, including why `Subnet`/`NetworkSpace` does NOT exhibit this pattern
• `cic-schema-registry` PR #152 — where this was found (did not introduce it; the `cluster_id`+`cluster_ref` duplication predates it, PR #152 just made the full parent key visible in the child address)