cs/manifest: Fix scrubber false positive for replaced segments

The scrub false-positive filter in process_anomalies() only checked
whether a segment with the same offset range existed in the manifest.
A compacted reupload produces a replacement segment at the same
offset range but with a different name (different size). When GC
deleted the old segment from cloud storage while the scrubber was
still referencing a stale manifest, the filter kept the anomaly
because the offset range still matched—even though the current
segment at that range was a different (replacement) object that
existed in cloud storage.

Compare generate_remote_segment_name() for the manifest entry and
the reported-missing segment so that replacements with the same
offset range but different identity are correctly recognized as
false positives.

Fixes CORE-6913.

Signed-off-by: Oren Leiman <oren.leiman@redpanda.com>

Author: oleiman

src/v/cloud_storage/partition_manifest.cc

@@ -2769,11 +2769,25 @@ void partition_manifest::process_anomalies(
 
         if (meta.committed_offset >= get_start_offset()) {
             // The segment might have been missing because it was merged with
-            // something else. If the offset range doesn't match a segment
-            // exactly, discard the anomaly. Only segments from the STM
-            // manifest may be merged/reuploaded.
-            return !segment_with_offset_range_exists(
-              meta.base_offset, meta.committed_offset);
+            // something else or replaced by a compacted reupload. Only
+            // segments from the STM manifest may be merged/reuploaded.
+            auto iter = find(meta.base_offset);
+            if (
+              iter == end()
+              || iter->committed_offset != meta.committed_offset) {
+                // Offset range no longer matches any segment in the
+                // manifest (merged or reuploaded with different
+                // boundaries). Discard the anomaly.
+                return true;
+            }
+            // The offset range still exists. Verify the current segment
+            // is the same one reported as missing, not a replacement
+            // (e.g., a compacted reupload with the same offset range but
+            // different size/term). If a different segment now covers
+            // the range, the old one being absent from cloud storage is
+            // expected.
+            return generate_remote_segment_name(*iter)
+                   != generate_remote_segment_name(meta);
         } else {
             // Segment belongs to the archive. No reuploads are done here.
             return false;
@@ -2790,10 +2804,18 @@ void partition_manifest::process_anomalies(
           }
 
           if (anomaly_meta.at.committed_offset >= get_start_offset()) {
-              // Similarly to the missing segment case, if the boundaries of the
-              // segment where the anomaly was detected changed, drop it.
-              return !segment_with_offset_range_exists(
-                anomaly_meta.at.base_offset, anomaly_meta.at.committed_offset);
+              // Similarly to the missing segment case, if the boundaries
+              // of the segment where the anomaly was detected changed or
+              // the segment was replaced (e.g., compacted reupload),
+              // drop the anomaly.
+              auto iter = find(anomaly_meta.at.base_offset);
+              if (
+                iter == end()
+                || iter->committed_offset != anomaly_meta.at.committed_offset) {
+                  return true;
+              }
+              return generate_remote_segment_name(*iter)
+                     != generate_remote_segment_name(anomaly_meta.at);
           } else {
               return false;
           }