Replace remaining `localeCompare` sorts on determinism-contract surfaces

[mbeacom]

Raised by @davesheffer on #106 and partly fixed there. This covers the remainder.

Why it matters

localeCompare depends on the runtime's ICU locale, so two environments order the same string set differently:

localeCompare : [src/a_b.ts, src/a-b.ts, src/a.ts, src/A.ts, src/ab.ts, src/aB.ts]
code-unit     : [src/A.ts, src/a-b.ts, src/a.ts, src/aB.ts, src/a_b.ts, src/ab.ts]

#106 fixed the two load-bearing instances — markers/read.ts, which decides which files survive the 3,000-path cap, and the markerScan path lists, whose skippedPaths order feeds cappedScanFinding's slice(0, 10). Both now use compareCodeUnits from packages/core/src/ordering/, which already existed.

The remaining sites are not merely display order. CheckOutcome documents itself as:

Deterministic and pure: identical (lint, changedFiles, snapshots, markerScans) produces identical output.

These arrays serialize into adr check --json, which @adrkit/ci consumes. Under a different ICU locale, identical inputs produce different output bytes. The set membership is fixed; the contract is about the bytes.

Known sites

• packages/core/src/check/index.ts — uniqueSorted, applied to changedFiles. Pre-dates feat(core,ci): wire inbound @adr markers into check #106.
• packages/core/src/markers/resolve.ts — compareDeclarations and the recordId sort.
• packages/ci/src/changed-files.ts — the changedFiles / markerFiles sorts and the changed-dependency sort.

Worth a sweep rather than a spot fix, since compareCodeUnits already exists and the anomaly was reaching for localeCompare at all.

Worth considering alongside

A lint rule or test that fails on a new localeCompare in any path that reaches serialized output. Otherwise the next one lands the same way this batch did.

[davesheffer]

Happy to take this one, since it grew out of my #106 review. Plan: sweep the three known sites (check/index.ts uniqueSorted, markers/resolve.ts compareDeclarations + the recordId sort, ci/changed-files.ts) onto the existing compareCodeUnits, with a fixture asserting identical check --json bytes across locales. On the guard: I'd lean toward a small test that fails on any localeCompare outside packages/core/src/ordering/ so the next one can't land silently — will include it unless you'd rather keep that separate. DCO signed, PR this week.

[mbeacom]

Scope update after #117 and #119. This is now only the `packages/core/src/affects/**` remainder.

Closed so far:

• fix(core,ci): sort check --json surfaces by code unit, not localeCompare #117 — `CheckOutcome.changedFiles`, the shared `sortFindings` tuple, and the Action's `changedFiles` / `markerFiles` / changed-dependency lists.
• fix(core,ci): sort corpus discovery by code unit, not localeCompare #119 — `load/corpus.ts` (`discoverAdrFiles`, `discoverSkippedMarkdownFiles`, `expandRecordInputs`) and `validate/index.ts` (`scannedDirectories`, the `lintCorpus` `records` sort).

Remaining, all under the FR-004 freeze:

Site	Sort
affects/index.ts:62	compareFiredMatcher — type then pattern
affects/index.ts:237	matches.sort((a, b) => a.recordId.localeCompare(b.recordId))
affects/matchers/package.ts:101	changed dependencies — name then version

affects/index.ts:237 is the one that still moves check --json output. It is a total re-sort of the resolver's matches, so for distinct record ids it — not any migrated module — decides governedBy order. I confirmed this empirically while reviewing #119: feeding both possible records orders for a mixed-case ULID pair through checkChanges produced identical governedBy, and that output order was itself the locale order.

Two consequences worth recording before this is picked up:

1. Ids are not always numeric. The grammar is ^([0-9]{4,}|[0-9A-HJKMNP-TV-Za-hjkmnp-tv-z]{26})$ — the ULID branch is mixed-case Crockford base32, where localeCompare and code-unit ordering genuinely disagree. This is not a theoretical concern about exotic locales.
2. Until this lands, a clean run of packages/core/test/ordering-contract.test.ts means "no scanned module reaches for localeCompare", not "check --json is locale-independent end to end". The suite was renamed and its header rewritten in fix(core,ci): sort corpus discovery by code unit, not localeCompare #119 to say exactly that, so the distinction is not resting on anyone remembering this comment.

Unblocking needs authorization to touch the frozen tree (packages/catalog-envelope/test/no-core-schema-change.test.ts names any change there a violation), and the freeze-hash pins in packages/catalog-envelope/ will need regenerating in the same change. The migration itself is mechanical: compareCodeUnits is already imported throughout core, and compareByDisplayPath (#119) covers the path-comparison case if any is needed.