docs(execution-action-binding): record that the vectors cannot test member ordering

docs/spec/execution-action-binding-v1-vectors.json

@@ -1,6 +1,7 @@
 {
   "profile": "cmcp.execution-action-binding-vectors/1",
   "contract": "docs/spec/execution-action-binding.md",
+  "member_ordering_note": "This set does not test UTF 16 code unit member ordering versus code point ordering, RFC 8785 section 3.2.3. A member name in the supplementary plane sorts before BMP characters in U+E000 through U+FFFF under code unit ordering, but the v1 preimage's six members are fixed, ASCII named, and hold only strings or the integer 1, so a member name pair that would diverge under the two sort rules cannot exist in a conformant v1 preimage. See the Conformance evidence section of the contract doc for the full reasoning.",
   "vectors": [
     {
       "id": "EAB-001-ascii-sha256",

docs/spec/execution-action-binding.md

@@ -110,6 +110,8 @@ A conforming implementation MUST reproduce the canonical bytes and expected dige
 
 The semantic-adjudication witness in the vector file is deliberately not assigned an automatic `same_operation` or `different_operation` verdict. Its purpose is to require the implementation or integrating profile to name the governing semantics before admission.
 
+This vector set does not, and cannot, test whether an implementation sorts object members using 16 bit code units, the way RFC 8785 section 3.2.3 requires, or sorts them by raw Unicode code point instead. The two orders only disagree when an object carries one member name in the supplementary plane, above U+FFFF, which UTF 16 encodes as a surrogate pair starting somewhere in D800 through DBFF, sorting before BMP characters in U+E000 through U+FFFF, together with another member name in that U+E000 through U+FFFF range. The v1 preimage's member set is fixed to the six ASCII named members shown in the normative contract above, and every one of them holds a plain string or the integer 1, never a nested object. There is no way to add a member name pair that would actually diverge under the two sort rules without adding, renaming, or reinterpreting a member, and section 1 already forbids that. So a canonicalizer that sorts by code point instead of by code unit still reproduces every digest in this file and passes, and no vector we could add here changes that without breaking the contract it is supposed to test.
+
 ## Non-claims
 
 This contract does not by itself provide exactly-once execution, external-effect proof, crash-safe audit consistency, or replay permission. It also does not authorize activation of the non-operational execution registry foundation from #606. Those remain the integration and durability requirements owned by #565.