Reconcile Dance v2.1 docs with the name-addressed invocation foundation

[evomimic]

Reconcile Dance v2.1 specification and delivery plan with the name-addressed foundation

Summary

Reconcile the Dances v2.1 design specification and delivery plan with the post-#649 Schema 2.0 package layout and the implemented, name-addressed, schema-backed Dance invocation foundation.

The resulting documents characterize the foundation implemented by map-holons #652 and map-holons PR #654. PR #654 also delivers the separate operator-affordance inverse-name correction tracked by map-dev-docs #19.

Context

The earlier v2.1 specification and delivery plan contained contradictory or over-broad Dance guidance:

• DanceName was described as a property of DanceType, despite canonical Dance identity being inherited TypeDescriptor.TypeName.
• The relationship table used shortened Affords / AffordedBy, while Schema 2.0 uses AffordsDance / DanceAffordedBy.
• The plan assumed direct InvokesDance dispatch, legacy bridge retention, and a superseded dances-design-spec-revised.md source.
• QueryDance was described as having an adapter-specific affordance relationship instead of participating in the generic Dance affordance through its DanceType extension.
• Full descriptor-aware request/response validation and an AffordingHolonRequirement policy were presented as part of the foundational cutover, although they were deliberately deferred.

Target foundation

• DanceType identity is its inherited TypeDescriptor.TypeName; it has no separate DanceName property.
• DanceInvocation.DanceName is required and resolves through the required affording holon's effective AffordsDance members. No match or ambiguity is a binding/dispatch error.
• DanceType.RequestType / RequestTypeFor replaces DanceInput / DanceInputFor.
• The generic relationship pair is exactly AffordsDance / DanceAffordedBy, with DanceType as its target. LoadHolons and QueryDance extend DanceType and are substitutable targets of that one relationship.
• LoadHolons and QueryDance bind through a required affording HolonSpace or subtype; there is no QueryDance-specific affordance relationship.
• LoadHolons and QueryDance are their respective canonical DanceNames; map.query.execute is only a transport or API alias.
• InvocationSource is stamped internally by ingress, not supplied by a caller.
• The clean-slate target removes superseded schema and runtime bridges rather than retaining them for compatibility.

Deferred work

• Shared descriptor-aware structural validation of Dance requests and successful responses remains a Validation-track integration. Dance must not add a local substitute validator.
• An AffordingHolonRequirement = Required | Optional | Prohibited policy is not part of the current foundation.
• Query execution behind QueryDance, dynamic Dance implementation selection, the full DAHN → TS SDK → Commands → Dance vertical slice, and TrustChannel / Agreement authorization remain separate work.

Scope

• Update the Dance design specification and implementation plan to state the foundation and deferred work consistently.
• Reconcile adjacent Dance, Command, and Query documents that assert conflicting Dance names, affordance names, invocation identity, or legacy-retention posture.
• Document that structural validation is a shared follow-up capability and that TrustChannel/Agreement disclosure authorization is outside this issue's scope.
• Cross-link the paired map-holons implementation issue and implementation PR.

Acceptance criteria

• No normative Dance document assigns a separate DanceName property to DanceType or treats a transport alias as canonical identity.
• The specification and plan use AffordsDance, DanceAffordedBy, RequestType, and RequestTypeFor.
• The documents describe LoadHolons and QueryDance as DanceType extensions reached through the required affording HolonSpace and the single generic Dance affordance relationship.
• Invocation resolution through the affording holon's effective affordances is unambiguous; no QueryDance-specific affordance relationship is retained.
• The plan identifies descriptor-aware request/response validation and any affording-holon policy enum as deferred shared follow-up work, without prescribing a Dance-local validator.
• Legacy bridge coexistence is not presented as a target requirement.
• QueryDance engine execution and TrustChannel/Agreement authorization are explicitly excluded from this issue's scope.
• The paired map-holons #652 and map-holons PR #654 are cross-linked.