Fix race condition causing permanent loss of active rule files

When a repository update arrives, the stream handler removes rules from
the path_to_rules HashMap and re-inserts them asynchronously after
processing. If a second update arrives during this async gap (e.g. from
a git checkout or atomic file save), the remove returns None and the
update is silently dropped. If the first update was a deletion and the
dropped second update was the corresponding addition, the rules are
permanently lost until client restart.

Fix: clone the rules instead of removing them, so they remain available
in the HashMap during async processing. Queries see slightly stale
(pre-update) rules during the gap instead of no rules at all.

Co-Authored-By: Oz <oz-agent@warp.dev>

Author: szgupta

crates/ai/src/project_context/model.rs

@@ -25,7 +25,7 @@ pub struct ProjectRule {
     pub content: String,
 }
 
-#[derive(Debug, Default)]
+#[derive(Debug, Default, Clone)]
 struct RuleAtPath {
     parent_path: PathBuf,
     warp_md: Option<ProjectRule>,
@@ -69,7 +69,7 @@ fn matches_rules_pattern(file_name_str: &str) -> bool {
     false
 }
 
-#[derive(Debug, Default)]
+#[derive(Debug, Default, Clone)]
 struct ProjectRules {
     rules: Vec<RuleAtPath>,
 }
@@ -345,7 +345,7 @@ impl ProjectContextModel {
                     return;
                 }
 
-                let existing_rules = me.path_to_rules.remove(&path_clone);
+                let existing_rules = me.path_to_rules.get(&path_clone).cloned();
                 let repo_path = path_clone.clone();
                 if let Some(rules) = existing_rules {
                     let repo_path_for_closure = repo_path.clone();