[#4705] Skip interceptor members when applying @SequencingPolicy

[abuijze]

Resolves #4705.

A class-level @SequencingPolicy was applied to any member able to handle EventMessages, which includes @ExceptionHandler and other interceptor members. The declared policy was then eagerly constructed against the member's payload type, which for an exception handler is the exception type. Property-based policies fail construction against that type, aborting component inspection and application startup for any projection combining a property-based class-level @SequencingPolicy with an @ExceptionHandler.

Interceptor members never participate in sequencing (AnnotatedEventHandlingComponent only consults the sequencing wrapper for subscribed event handlers), so MethodSequencingPolicyEventHandlerDefinition now excludes them by checking for the MessageHandlerInterceptor.messageType attribute. Every interceptor member carries this attribute through annotation scanning, since @ExceptionHandler is meta-annotated with @MessageHandlerInterceptor and @ResultHandler only exists as a meta-annotation. This makes the check independent of the order in which handler enhancers wrap the member.

Includes an enhancer-level regression test asserting the exception handler member stays unwrapped, and the issue's AnnotatedHandlerInspector.inspectType reproducer. Both fail without the fix.

[MateuszNaKodach]

This key derivation is now duplicated: MessageHandlerInterceptorDefinition.wrapHandler builds the identical "MessageHandlerInterceptor.messageType" string as a local variable, and this enhancer must stay in sync with it for the skip to work — if the key ever changes there, this check silently stops matching and the #4705 startup failure returns with no compile-time signal. Severity is low (the key is unlikely to change), but consider defining a shared constant, e.g. next to HandlerAttributes.MESSAGE_TYPE which already follows the same naming scheme, and referencing it from both definitions.