refactor: switch internal maps/sets from HashMap to IndexMap

Adopt indexmap workspace-wide so iteration order is deterministic and
follows insertion order. The non-deterministic order of std HashMap
otherwise leaks into resolver decisions when multiple valid solutions
exist (e.g. cyclic require pairs under prefer-lowest), making behavior
flaky and divergent from Composer's PHP-array semantics.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

1 files changed, 2 insertions, 2 deletions

diff --git a/crates/mozart-sat-resolver/src/problem.rs b/crates/mozart-sat-resolver/src/problem.rs
index c453fa9..a1692fd 100644
--- a/crates/mozart-sat-resolver/src/problem.rs
+++ b/crates/mozart-sat-resolver/src/problem.rs
@@ -75,7 +75,7 @@ impl Problem {
         }
 
         // Deduplicate
-        let mut seen = std::collections::HashSet::new();
+        let mut seen = indexmap::IndexSet::new();
         let mut unique = Vec::new();
         for msg in messages {
             if seen.insert(msg.clone()) {
@@ -367,7 +367,7 @@ fn rule_pretty_string(pool: &Pool, rule: &Rule) -> String {
 /// Similar to Composer's formatPackagesUnique.
 fn format_providers(pool: &Pool, literals: &[Literal]) -> String {
     // Group by package name
-    let mut groups: std::collections::HashMap<&str, Vec<&str>> = std::collections::HashMap::new();
+    let mut groups: indexmap::IndexMap<&str, Vec<&str>> = indexmap::IndexMap::new();
     for &lit in literals {
         let pkg = pool.literal_to_package(lit);
         groups