Memory-growth triggers misfire after you start freeing buffers: regrowth counts as growth

A streaming writer started a new output segment when its accounted memory grew past a threshold since the last cut. A later fix made the writer release per-signal buffer capacity when each block closed. That cut peak memory by half, but the trigger then fired far more often (8 to 194 cuts on a small test), roughly doubling the file. The buffers that were freed at a cut regrow on the next block, and the trigger counted that regrowth as new growth. Lessons: (1) when you change what memory a component releases, re-check every policy that reads its memory counter, not just the memory numbers; (2) a growth-since-last-event trigger is sensitive to anything released at the event, so prefer triggering on growth of the component that actually accumulates (e.g. accounted minus reusable buffers), or on an absolute threshold; (3) a test with both a lower and an upper bound on the trigger count catches both never-fires and over-fires; (4) byte-identity checks should be run with the trigger off, because changed cut points legitimately change bytes.