fix(evaluator): a cleanup that already succeeded is not an error

`Sandbox::purge` removes the verification copy, and then `Drop` runs
`remove_dir_all` on the path purge just deleted and prints a failure. Prod
logged it on every mission:

    evaluator_tools: could not remove the verification copy at
    /var/lib/clawmates-missions/_verify/01a07812-… (No such file or directory)

That is the success path reporting itself as a fault. It matters beyond
tidiness: this is the same line that carries a REAL stranded-copy error, and a
message that cries wolf once a mission is a message nobody reads the day it is
true — which is how two root-owned copies sat stranded for hours the first
time.

`NotFound` is now the expected outcome and says nothing. Every other error
still speaks.

Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01WZb5A2kfVfjpdwSochkuHz

crates/cm-api/src/evaluator_tools.rs

@@ -431,11 +431,17 @@ impl Drop for Sandbox {
             return;
         }
         if let Some(root) = self.workdir.parent() {
-            if let Err(e) = std::fs::remove_dir_all(root) {
+            match std::fs::remove_dir_all(root) {
-                eprintln!(
+                Ok(()) => {}
+                // Already gone, because `purge` ran first and worked. That is
+                // the SUCCESS path, and reporting it as a failure is how a
+                // real cleanup error gets read as noise — the exact habit that
+                // let two root-owned copies sit stranded for hours.
+                Err(e) if e.kind() == std::io::ErrorKind::NotFound => {}
+                Err(e) => eprintln!(
                     "evaluator_tools: could not remove the verification copy at {} ({e})",
                     root.display()
-                );
+                ),
             }
         }
     }