Problem

Coverage data is currently stored in MessageResults.AdditionalResults during transaction execution, then manually cleaned up at multiple call sites to prevent memory retention. This pattern is fragile — missing cleanup at any site causes memory leaks, as confirmed by pprof profiling (~8 MB/min growth from coverage maps retained in the corpus pruner).

Current cleanup sites

1. Corpus.Initialize (fuzzing/corpus/corpus.go, lines 236-250) — iterates all blocks/messages after chain clone and removes coverage tracer results
2. checkSequenceCoverageAndUpdate (fuzzing/corpus/corpus.go, line 390) — removes coverage from the last call's message results after extracting it
3. PruneSequences (fuzzing/corpus/corpus.go, added in memory leak fix) — removes coverage from all elements in each replayed sequence, since checkSequenceCoverageAndUpdate only cleans the last element

Proposed approach

Extract coverage directly from CoverageTracer rather than round-tripping through AdditionalResults:

• After each call sequence execution, query the CoverageTracer for accumulated coverage maps
• This eliminates the need to store coverage in AdditionalResults at all
• No storage means no cleanup needed — the retention-leak pattern disappears at its source
• The tracer already tracks this data internally; AdditionalResults is just a transport mechanism

Benefits

• Single source of truth for coverage data (the tracer)
• No more scattered cleanup calls that must stay in sync
• Eliminates an entire class of memory leaks
• Simpler mental model for contributors