Consolidate Spring test-context configurations to reduce context-cache fragmentation

[ivosh]

Description

Test-suite wall-clock time is dominated by how many distinct Spring contexts boot, not how many tests run: every unique combination of @MockitoBean fields, active profiles, and property sources is a separate context-cache key that forces a full multi-second context boot.

Current fragmentation signals in src/test/java:

• 36 files use @MockitoBean, with the same beans mocked repeatedly in different files (NotificationProducer in 5 files, PollFeature in 3, several others in 2) — each spelling a fresh context configuration.
• The messaging tests spell @ActiveProfiles three different ways (value = {"messaging-int-test"}, inheritProfiles = false / {"messaging-int-test"} / value = {"messaging-int-test"}), which may split the cache further.

Consolidate recurring mock sets into shared @TestConfiguration on the context base classes (BaseSpringBootTest, BaseMessagingIntTest), normalize the @ActiveProfiles spellings, and finish with a guard test capping the distinct context-configuration count so fragmentation cannot silently regress.

Best executed after the per-package migration under #1693 is largely complete, when context-loading tests live under the single com.otilm.core.integration root and the change surface is one package tree. Complements #1693: without it, the dedicated integration CI job just relocates the slowness.

Definition of Done

• Census script/report enumerating distinct Spring context configurations (baseline count recorded)
• Recurring mock sets consolidated into shared @TestConfiguration on the context base classes
• @ActiveProfiles spellings normalized to one canonical form
• Guard test asserts the distinct context-configuration count stays at or below the consolidated baseline
• Integration-job wall-clock and context-boot count measured before/after consolidation