Add generic peak cycle detector

PROJECT_KNOWLEDGE.md

@@ -17,6 +17,30 @@ ENLYZE and is retrieved again when historical calculations need reproduction.
 - Calculations are modular, testable Python implementations. Configuration
   declares instances; it is not a generic low-code language.
 
+## Peak-cycle detector
+
+The first generic calculation is a timestamp-based `PeakCycleDetector` under
+`calculations`. It is transport-independent and works for roll length, roll
+weight, and similar cyclic signals. It maintains the maximum in an open cycle;
+after a value falls below `drop_ratio * current_peak`, it emits that maximum
+only after actual subsequent below-threshold observations support a continuous
+`hold_seconds` interval. `min_peak` is a generic detector setting, along with
+`drop_ratio` (0 < ratio < 1), `hold_seconds` (>= 0), and an explicit positive
+`max_sample_gap_seconds`. Elapsed time, never a sample count, determines
+confirmation. An interval longer than the configured maximum sample gap
+restarts a reset candidate, so a timestamp gap is not
+continuous-below evidence. Reset values can be negative rather than zero,
+equal timestamps add no elapsed time, and backwards timestamps are rejected.
+The maximum gap is required rather than inferred or defaulted, making each
+source's continuity assumption explicit.
+
+K7 roll length, variable `bf81c547-dccf-4709-aee2-0f78366d1dfc` (m), is the
+first real-world validation case. The tested capture is continuous on a
+10-second grid through its latest available sample; its shorter-than-requested
+result was caused by an end time queried in the future, not observed time-series
+gaps. The raw capture remains ignored and deterministic tests use synthetic
+fixtures only.
+
 ## Central domain context
 
 Production orders connect machine, article/material, source interval, and