[#4803] State what the default sequencing policy actually does on DCB stores

[schananas]

Fixes #4803

What changed

Documentation plus two pinning tests. No behaviour change, and that is deliberate -- see below.

SequencingPolicy named SequentialPerAggregatePolicy as the default when the wired default is HierarchicalSequencingPolicy(SequentialPerAggregatePolicy, SequentialPolicy), and Spring's EventProcessorProperties repeated the same wrong claim. On a DCB store the per-aggregate half resolves nothing, because only the aggregate-based storage engines publish LegacyResources.AGGREGATE_IDENTIFIER_KEY, so the fully-sequential fallback answers every event: one sequence identifier, one segment, every other segment idle whatever the configured segment and thread count.

Corrected at every place that stated the contract wrongly or incompletely: SequencingPolicy, SequentialPerAggregatePolicy, the SimpleEventHandlingComponent factory method that installs the default, EventProcessorProperties, and both the streaming and migration reference-guide pages, which are sharpened from "sequentially within a single segment" to the real claim that every other segment receives nothing.

Why no behaviour change

A DCB event may carry several tags. Keying on one of them would put two events that share that tag but differ in the others into different sequences and lose their relative order. A single constant is the only safe fallback, so the throughput cliff is inherent to a safe default and the defect is the silence.

That argument is the thing to review hardest. The real question -- should a DCB store publish a per-entity resource the default policy can read? -- is a design decision for the framework owners and is stated in #4803 rather than answered here.

Tests

Two new cases in SimpleEventHandlingComponentSequencingPolicyTest.DefaultSequencingPolicyWithoutAnAggregateIdentifier. Nothing can "fail without the fix" since no behaviour changed, so they were validated the other way: mutating the wired default's fallback from SequentialPolicy to FullConcurrencyPolicy turns both red (Expected size: 1 but was: 3). They pin the measurement, so they go red the day the default starts resolving per-entity on a DCB store.

messaging module green; extensions/spring/spring-boot-autoconfigure compiles.

Merge note

SimpleEventHandlingComponent.java and its sequencing-policy test are also touched by #4797's branch, in different regions of each file. Both branch off the same base blobs, so whichever merges second should rebase rather than resolve by hand.