stdlib: add locale-sensitive comparison with independently versioned policy

Context

Split out of #42 so that the spec obligation is fully tracked rather than partly closed.

Two accepted specs require five Unicode operations:

Scalar decoding, normalization, grapheme segmentation, case mapping, and locale-sensitive comparison SHALL be ordinary, explicitly invoked stdlib behavior.
— openspec/specs/bootstrap-silk-stdlib/spec.md:269-273

Unicode normalization and locale-sensitive comparison SHALL be explicit stdlib operations with independently versioned policy.
— openspec/specs/bootstrap-string/spec.md:106-108

#42 covers normalization, grapheme segmentation and case mapping, and explicitly lists locale-sensitive comparison as out of scope. Scalar decoding already exists. So #42 closing does not discharge the cited SHALL — this issue is the remainder, and the clause is only satisfied when both are done.

That gap was caught in triage on #42 and is the reason for this split: an issue that cannot close the obligation it cites will otherwise be closed as though it had.

Why it is separated rather than folded in

Collation needs locale data, which the other four operations do not. That is a different data pipeline, a different versioning story, and a different size of problem from the canonical decomposition and case tables. Folding it into #42 would make one already-large lane into two unrelated ones.

Requirements

1. A locale-sensitive comparison is an explicitly invoked stdlib operation. Ordinary string equality and ordering stay exact and locale-free — this must not change them.
2. The collation policy is independently versioned, and the version is a named, separately testable value.
3. A later collation data version must not change the compiler type identity, and must not change the target ABI.
4. No collation table enters the compiler.
5. The locale is an explicit argument. There is no ambient or default locale, and nothing consults the environment.

Open questions — this is needs-definition on purpose

• Which collation algorithm and to what level. Full UCA with tailoring is very large; a root-collation-only subset is far smaller and covers most of the value. This choice dominates the size of the work.
• How a locale is spelled. A BCP 47 tag as string, a nominal type, or a small closed enum.
• Where the locale data lives. #42 decided generated .silk under stdlib:generate for the Unicode tables; the same answer may or may not suit locale data, which is larger and more frequently revised.
• Whether tailoring is in scope at all, or whether root collation is the whole of this issue with tailoring deferred again — in which case the deferral should be recorded here rather than left implicit.

Answering the first and last of those is what makes this actionable.

Out of scope

• Everything #42 owns: NFC/NFD normalization, grapheme segmentation, case mapping.
• The NFKC and NFKD compatibility forms.
• A bidirectional text algorithm.

Related

• #42 — the other four operations of the same spec clause. Neither issue discharges it alone.

Filed by orchestrator run run-r7x1, from a triage finding on #42.

Start with openspec/specs/bootstrap-silk-stdlib/spec.md:269-273 and openspec/specs/bootstrap-string/spec.md:106-108, then review #42's scope. Define the collation algorithm and tailoring decision, locale representation, and data/versioning approach; done means an explicit locale-sensitive operation meets the five listed requirements without changing exact string ordering, compiler type identity, or target ABI.