research/start: allow rerun on loop-owned topics too

D1-fold loop guard 409'd even the rerun path if the topic was
scheduled — a failed iteration couldn't be restarted until the loop's
next scheduled fire. Now the loop guard only fires for the fresh
'standby' start; the rerun path (status=='processing' + orphan
cancel) works whether or not a loop owns the topic. Loop binding is
preserved either way.

crates/cm-api/src/routes/research.rs

@@ -703,12 +703,19 @@ pub async fn start_topic(
     // already owns this topic. Otherwise clicking the legacy "Start
     // research" button while a loop iteration is in flight would spawn
     // a competing run through the classic path.
-    if cm_db::repo::loops::research_loop_for_topic(&state.pool, id)
+    //
+    // Exception: the rerun path (status = "processing" + orphans just
+    // cancelled) should be allowed even when a loop owns the topic.
+    // Otherwise a failed scheduled iteration is un-restartable until
+    // the loop's next scheduled fire — the user has to wait or delete
+    // the topic and re-enter the wizard. Rerun preserves the loop
+    // binding.
+    let loop_owned = cm_db::repo::loops::research_loop_for_topic(&state.pool, id)
         .await
         .ok()
         .flatten()
-        .is_some()
+        .is_some();
-    {
+    if loop_owned && topic.status == "standby" {
         return Err(ApiError::Conflict);
     }
     let slots = cm_db::repo::research_topics::agents(&state.pool, id).await?;