Detect duplicate names before building an object

Compare decoded names within each object; do not confuse object order with array order.

• Objects in I-JSON MUST NOT have members with duplicate names. Compare the Unicode character sequences after processing escapes (§2.3). In {"a":1,"\u0061":2}, both names decode to a, so the object fails even though its source spellings differ.
• Duplicate detection must preserve the incoming member sequence long enough to see both names. Applying a first-wins or last-wins map conversion and then checking its keys loses that evidence. The illustration stops at the duplicate gate before accepting an object; it does not invent a JSON error packet (§§2.3,3).
• The scope is each object. {"left":{"x":1},"right":{"x":2}} does not duplicate a member name in the same object. Conversely, a repeated name in a nested object still violates the rule. Keys such as __proto__ are ordinary names for this profile, not permission to mutate a language prototype.
• Order of object members does not change I-JSON meaning; receivers MAY treat messages differing only in member order as equivalent (§2.3). This is not canonical byte order and does not reorder arrays. [1,2] and[2,1] remain different ordered JSON arrays.
• Compare decoded sequences without silently normalizing them. The name é (U+00E9) differs from e followed by U+0301; case also remains significant. I-JSON does not require these distinct names to be merged. Schema/application restrictions may be stricter, and a valid name is not trusted authority.