#3324 fix: compile-check walks local packages in a fixed order

Summary

• uloop compile-check now walks packages developed from a local path (file: dependencies) in the same order on every run, so its result no longer changes between two runs on an unchanged project.

User Impact

• Before: with two or more local packages, the order of their roots followed Go's random map order. When two of those packages declared the same assembly name, which one was used changed from run to run, and when several roots were broken, which error was reported first changed too.
• After: the roots come in the order of the dependency names in Packages/manifest.json, so the same assembly definition wins and the same error is reported every time.

Changes

• The local package roots are resolved after sorting the manifest's dependency names. Unity itself rejects two assemblies with the same name, so no winner is more correct than another; the fix only makes the choice the same every run.
• Duplicate roots (two names pointing at the same place) are still kept, and the order of the built-in roots is unchanged.

Verification

• Two new tests, each repeating the call 20 times: the roots of four local packages listed out of name order (with a registry dependency among them) come back in name order; and of two local packages declaring the same assembly name, the one whose dependency name comes first is indexed. Both failed against the previous code on the first run.
• cli/dispatcher: golangci-lint fmt --diff (empty), go vet ./..., golangci-lint run (0 issues), the complexity config (0 issues), go test ./..., and go test -race ./internal/compilecheck/... pass. Coverage with the CI exclusions: 94.30% (baseline 94.2).
• cli/release-automation: go test ./... passes. The file-length check passes.
• Mutation check, restored afterwards: removing the sort fails both new tests on each of three runs (-count=3).