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/request.rs b/crates/mozart-sat-resolver/src/request.rs
index 94891f0..26c17ba 100644
--- a/crates/mozart-sat-resolver/src/request.rs
+++ b/crates/mozart-sat-resolver/src/request.rs
@@ -1,5 +1,5 @@
 use crate::pool::PackageId;
-use std::collections::HashMap;
+use indexmap::IndexMap;
 
 /// A requirement: package name + version constraint string.
 #[derive(Debug, Clone)]
@@ -14,7 +14,7 @@ pub struct Require {
 #[derive(Debug, Clone)]
 pub struct Request {
     /// Root requirements: package name → constraint string.
-    pub requires: HashMap<String, Option<String>>,
+    pub requires: IndexMap<String, Option<String>>,
     /// Fixed packages (must be installed, cannot be modified).
     pub fixed_packages: Vec<PackageId>,
     /// Locked packages (installed but can be removed if nothing requires them).
@@ -24,7 +24,7 @@ pub struct Request {
 impl Request {
     pub fn new() -> Self {
         Request {
-            requires: HashMap::new(),
+            requires: IndexMap::new(),
             fixed_packages: Vec::new(),
             locked_packages: Vec::new(),
         }