derive ComposedEdgeType from _MEMBER_EDGE_COMPOSED_REL_MAP

[HumanBean17]

Context

PR #171 landed DECLARES.* dot-key traversal for neighbors. Composed keys are defined in three places today:

1. kuzu_queries._MEMBER_EDGE_COMPOSED_REL_MAP — Cypher rollup + traversal
2. mcp_v2.ComposedEdgeType — Pydantic Literal + _COMPOSED_EDGE_TYPES
3. java_ontology._COMPOSED_MEMBER_TYPE_TRAVERSAL — EDGE-NAVIGATION doc generator strings

Adding a fourth composed member path (or renaming a key) requires editing all three manually.

Proposal

Single source of truth: export composed dot-key strings from kuzu_queries._MEMBER_EDGE_COMPOSED_REL_MAP (or a small shared module both kuzu_queries and mcp_v2 import).

• Build ComposedEdgeType / _COMPOSED_EDGE_TYPES from map keys at runtime (or generate the Literal via typing helpers / a single tuple re-export).
• Optionally derive java_ontology._COMPOSED_MEMBER_TYPE_TRAVERSAL edge segment from the same keys (template already uses {edge} for the stored rel suffix).

Acceptance

• One tuple (or module constant) defines composed keys; no duplicated string literals across kuzu_queries, mcp_v2, and doc tooling.
• Existing tests for dot-key neighbors + describe rollup parity still pass.
• No ontology version bump unless traversal semantics change.

Related

• Landed: feat(neighbors): navigate DECLARES.* composed edge types in one call #171, NodeRef lacks edge-presence signals — agent cannot see client/producer/route declarations without describe #162
• Follow-up from PR feat(neighbors): navigate DECLARES.* composed edge types in one call #171 review (non-blocking drift note)