Code domain's imports dimension doesn't honor its own 'unordered set' merge semantics: reorder + add still produces a false conflict

Found while building Episode 01 ("The Whole Workflow") demo material, verified live in both real git and real muse before filing.

The dimension's documented contract: the code domain's imports dimension is described as "Import set. Tracks added / removed import statements as an unordered set — order is semantically irrelevant," and is listed among the code domain's independently-mergeable dimensions.

Case that works exactly as promised (verified): two branches each independently add a different import, no reordering —

base:   import os / import re
branch A: + import sys
branch B: + import json

muse merge feature/add-sys   -> Fast-forward
muse merge feature/add-json  -> Merge made by the three-way strategy.
# result: import os / import re / import sys / import json — clean, no conflict

This is the real, working case and it's genuinely good — a plain-git merge of the identical two branches produces a real CONFLICT (content) on the same insertion point, and muse doesn't.

Case that violates the documented contract (verified): one branch purely reorders the existing imports (no additions/removals), the other branch adds one new import —

base:     import sys / import os / import re
branch A: import os / import re / import sys        (pure reorder)
branch B: import sys / import os / import re / import json  (pure addition)

muse merge feature/alphabetize -> Fast-forward
muse merge feature/add-json    -> CONFLICT (both modified): app.py

<<<<<<< main [inserted]
import sys
||||||| base
=======
import json [inserted]
>>>>>>> end conflict

If imports were genuinely diffed/merged as an order-irrelevant set, branch A's reorder should be indistinguishable from a no-op at this dimension (same set, same elements), and branch B's addition should merge as a trivial set union — matching the add+add case above. Instead it falls back to the same literal line-position conflict a line-based tool would produce, which is exactly the failure mode the "unordered set" semantics are supposed to prevent.

Suggested fix: whatever diff/merge path handles the imports dimension needs the reorder-only case to normalize to "no change" (or at minimum, to be recognized as commuting with a pure addition) rather than falling through to file-level/line-level conflict detection. Worth checking whether this is specific to imports or affects the variables dimension too, since it's described with the same unordered-set model.

Not urgent — this is an edge case (add+add already works, the common case), not the primary failure mode. Deferred per usual until after the season wraps.