Add `EventStore` method to convert `TrackingToken` to `ConsistencyMarker` (breaking change)

[MateuszNaKodach]

The task was discussed on Axon Framework meeting 2026-02-05.

Feature Description

Add a method to the EventStore interface that converts a TrackingToken into a ConsistencyMarker. This enables asymetric SourcingCriteria and AppendCriteria, as well as it enables other components (such as workflows, which do streaming - not sourcing) to conditionally append events using the tracking token's position as the consistency boundary, without needing to perform event sourcing first.

The conversion is implementation-specific because a TrackingToken can take many forms (GlobalSequenceTrackingToken, MultiSourceTrackingToken, ReplayToken, MergeToken, etc.), and each EventStore implementation knows how to interpret the token it produced and derive the appropriate ConsistencyMarker.

The method should throw an exception if the provided TrackingToken cannot be converted (e.g., a multi-source token that doesn't belong to this store).

Current Behaviour

Currently, the only way to obtain a ConsistencyMarker is through the sourcing path: EventStoreTransaction.source(SourcingCondition) sources events and produces a ConsistencyMarker as a side effect. This means that any component wanting to conditionally append events must first perform sourcing, even if it doesn't need the sourced events.

There is no API to construct a ConsistencyMarker from a TrackingToken directly. The two concepts live in different layers of the framework:

• TrackingToken (messaging module) — tracks position for event processors in a StreamableEventSource
• ConsistencyMarker (eventsourcing module) — tracks position for consistency validation during event appending

Despite both representing positions in an event stream, there is no bridge between them.

Wanted Behaviour

A new method on EventStore that accepts a TrackingToken and returns the corresponding ConsistencyMarker. This enables:

1. Conditional event appending without sourcing — workflows and other components that consume event streams can append events with an AppendCondition derived from their tracking position, ensuring no conflicting events occurred since that position.
2. Decoupling sourcing from appending — components no longer need to perform a dummy sourcing operation just to obtain a ConsistencyMarker.
3. Implementation-specific validation — the EventStore can validate whether the given TrackingToken is compatible and perform any necessary transformations (e.g., for the GlobalSequenceTrackingToken, extract the global index and create a GlobalIndexConsistencyMarker

Possible Workarounds

Perform a no-op sourcing operation to obtain a ConsistencyMarker:
This is semantically incorrect and wasteful — it forces a round-trip to the event store purely for the side effect of producing a ConsistencyMarker, and requires constructing a SourcingCondition that may not match the actual intent.