fix(update): unlock new-package deps via repo requires for --with-deps

`expand_with_direct_dependencies` only walked the lock map, so an
allow-listed package not yet in the lock (a freshly added root require)
contributed nothing to the unlock cascade. The resolver then kept
transitive deps pinned to their lock versions and bailed when the new
package's require could not be satisfied. Mirror Composer's
`PoolBuilder::loadPackage` by also walking inline / composer-repo
require lists for not-yet-locked packages.

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

1 files changed, 8 insertions, 2 deletions

diff --git a/crates/mozart/src/commands/remove.rs b/crates/mozart/src/commands/remove.rs
index dc20a21..3ffe04a 100644
--- a/crates/mozart/src/commands/remove.rs
+++ b/crates/mozart/src/commands/remove.rs
@@ -335,14 +335,20 @@ pub async fn execute(
             .map(|s| s.trim().to_lowercase())
             .collect();
 
+        let repo_requires = super::update::collect_repo_requires(&raw.repositories);
         let allow_list = if args.no_update_with_dependencies {
             // Only the removed packages themselves are freed
             removed_names
         } else if with_all_deps {
-            super::update::expand_with_all_dependencies(removed_names, lock)
+            super::update::expand_with_all_dependencies(removed_names, lock, &repo_requires)
         } else {
             // Default: freed packages + their direct dependencies
-            super::update::expand_with_direct_dependencies(removed_names, lock, &IndexSet::new())
+            super::update::expand_with_direct_dependencies(
+                removed_names,
+                lock,
+                &IndexSet::new(),
+                &repo_requires,
+            )
         };
 
         // For --minimal-changes, additionally pin packages beyond the allow list