feat: Handle analyze retry with failure marker

When a previous analysis attempt fails and leaves a failure marker, the
retry mechanism now correctly identifies this state. It removes the
stale
input file, allowing the retry to proceed without a conflict error. This
ensures users can recover from analysis failures more gracefully.

server/src/routes/case_actions.rs

@@ -14,6 +14,7 @@ use tracing::{info, warn};
 use doctate_common::timestamp::{filename_stem_to_recorded_at, now_rfc3339};
 use doctate_common::{RECORDING_META_SUFFIX, TranscriptState};
 
+use crate::analyze::auto_trigger::FAILURE_MARKER_FILE;
 use crate::analyze::backend::{any_backend_available, find_backend};
 use crate::analyze::{
     ANALYSIS_INPUT_FILE, AnalysisInput, AnalyzeJob, AnalyzeSender, DOCUMENT_FILE, RecordingInput,
@@ -107,6 +108,17 @@ pub async fn handle_analyze_case(
 
     let input = build_analysis_input(&case_dir, &backend_id).await?;
     let input_path = case_dir.join(ANALYSIS_INPUT_FILE);
+
+    // Manual retry path: a failure marker means the worker has explicitly
+    // given up on the prior input. Drop the stale sentinel so create_new
+    // does not reject the legitimate retry as "Analyse läuft bereits".
+    // The marker itself is left in place — the worker overwrites it on
+    // re-failure and removes it on success, so the UI's "analyzing" flag
+    // (driven by input file presence) takes over from the next render.
+    if case_dir.join(FAILURE_MARKER_FILE).exists() {
+        remove_if_exists(&input_path).await?;
+    }
+
     write_input_create_new(&input_path, &input).await?;
 
     // Unbounded send: only fails if the worker has gone away (programmer error