[CodeDrivenMitch]

A customer reported a processor that was 50+ days behind, while all of its segments were at the head of the event store. Its Handler Insights also showed old events being handled by that processor. The events were fine. They belonged to a new processor in the same application that was replaying its history, and the client reported its measurements under the wrong processor name.

The cause is in AxoniqPlatformConfigurerEnhancer. It walks the processor modules with doOnSubModules and registers an AxoniqPlatformEventHandlingComponent decorator for each of them. However, doOnSubModules hands the block the parent registry, not the module's own registry. So with four processors, the parent gets four EventHandlingComponent decorators, each bound to a different processor name. AF5 copies the decorators of a parent into every module (DefaultComponentRegistry.copyWithDecoratorsAndEnhancers), so every processor's components get wrapped once per processor. Only the outermost wrapper records the measurement, so the ingest latency, commit latency and handler statistics of all processors end up under one name, keyed by each processor's own segment ids. That explains the "50 days behind" on a processor at the head: another processor's replay of 50-day-old events was written to its segment ids.

This PR registers the decorator on the processor module's own registry instead, through BaseModule.componentRegistry(...). Each processor now wraps only its own components, with its own name.

I added ProcessorMetricsAttributionIntegrationTest. It boots a real AF5 configuration with two pooled streaming processors and the enhancer loaded as in an application. Each processor handles an event of a different age, and the test checks that each one reports only its own latency and handler statistics. Before the fix, beta-processor reported 0 latency and BetaEvent was counted under alpha-processor.