harness: the order-invariance oracle silently declines on any document using YAML anchors

[OmarAlJarrah]

orderInvariant (internal/harness) permutes a spec with reverseMappings and compares the two compilations. It has four paths that return ("", true) — the source not surviving a re-encode, the permutation not being meaning-preserving, nothing to permute, and the baseline not compiling. Each makes the oracle decline to ask, and the spec is then reported ok, indistinguishable from having passed.

Reversing a document that uses YAML anchors lifts aliases above the anchors they refer to, which is not meaning-preserving, so reverseMappings refuses. Every merge-key construct is therefore invisible to the oracle — and merge-key expansion is memoized per View, which is exactly where order-dependence has now been found twice (#362's reverted shared view, and the pre-scan).

Verified: a spec with a 71-link merge chain whose verdict provably flips with declaration order sweeps ok.

Worth considering:

• report declines distinctly from passes, so a corpus-wide count of "specs the oracle could not ask about" is visible rather than folded into ok;
• permute in a way that preserves anchor/alias order, so anchored documents can be asked at all.

The first is cheap and would have made this visible; the second is the real fix. Found while probing #362.