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, 3 insertions, 3 deletions

diff --git a/crates/mozart-sat-resolver/src/rule_set.rs b/crates/mozart-sat-resolver/src/rule_set.rs
index 4d1a8a6..918bdae 100644
--- a/crates/mozart-sat-resolver/src/rule_set.rs
+++ b/crates/mozart-sat-resolver/src/rule_set.rs
@@ -1,5 +1,5 @@
 use crate::rule::{Rule, RuleType};
-use std::collections::HashMap;
+use indexmap::IndexMap;
 
 /// A unique identifier for a rule within the RuleSet.
 pub type RuleId = usize;
@@ -18,7 +18,7 @@ pub struct RuleSet {
     /// Total rule count.
     next_rule_id: usize,
     /// Deduplication index.
-    rules_by_hash: HashMap<String, Vec<usize>>,
+    rules_by_hash: IndexMap<String, Vec<usize>>,
     /// Maps rule ID → (type, index within type's vec).
     rule_type_index: Vec<(RuleType, usize)>,
 }
@@ -31,7 +31,7 @@ impl RuleSet {
             request_rules: Vec::new(),
             learned_rules: Vec::new(),
             next_rule_id: 0,
-            rules_by_hash: HashMap::new(),
+            rules_by_hash: IndexMap::new(),
             rule_type_index: Vec::new(),
         }
     }