collector: HashCounter::iter allocates O(BUCKETS) heap boxes via nested chain

[korniltsev-grafanista-yolo-vibecoder239]

⚠️ AI-generated issue — requires human investigation before acting on it.

Summary

HashCounter::iter in src/collector.rs builds a deeply-nested Box<dyn Iterator> chain by wrapping each of the 4096 buckets in a new Box::new(iter.chain(...)). This allocates 4096 heap objects every time a report is built.

Location

src/collector.rs, lines 137–145:

pub fn iter(&self) -> impl Iterator<Item = &Entry<T>> {
    let mut iter: Box<dyn Iterator<Item = &Entry<T>>> =
        Box::new(self.buckets[0].iter().chain(std::iter::empty()));
    for bucket in self.buckets[1..].iter() {
        iter = Box::new(iter.chain(bucket.iter()));   // ← 4095 allocations
    }
    iter
}

Impact

• 4096 heap allocations per call to try_iter / report build.
• Each next() call on the resulting iterator traverses a chain of 4096 dynamic dispatch steps before reaching a real element.
• O(N²) behaviour in the worst case when iterating through all entries.

Expected behaviour

Replace with a flat iterator:

pub fn iter(&self) -> impl Iterator<Item = &Entry<T>> {
    self.buckets.iter().flat_map(|b| b.iter())
}

This requires zero extra allocations and has O(1) dispatch overhead per element.