Fix InMemory stream Version not advancing on append

[artnim]

Summary

InMemoryEventStream.Version was a get-only property set in the constructor and never updated. AppendAsync writes each event with Version + 1, but since Version never moved off its initial value, every direct append produced an event at version 1 and the stream's reported tip stayed at 0.

This breaks any caller that relies on stream.Version reflecting the actual tip — most visibly the incremental aggregation overload AggregateAsync(stream, target, ct), which reads stream.Version as its targetVersion. With a stale tip, the loop's target.Version == targetVersion break can fire before any newly-appended events are applied, so incremental aggregation silently no-ops after the first append.

The Cosmos implementation already keeps Version in sync via the PatchItemAsync response on each append; the issue was specific to the in-memory store.

Fix

Derive Version from the events list, mirroring how LatestSnapshotVersion already works in the same class:

public ulong Version => _events.Count == 0 ? _initialVersion : _events.Max(e => e.Version);

The constructor-supplied version is kept as _initialVersion so an empty stream still reports the seed value. AppendAsync and AppendSnapshotAsync keep their Version = Version + 1 lines unchanged — they now read the live tip. InMemoryTransactionalBatch is unaffected.

Test plan

• New tests in InMemoryEventStreamTests pin the contract:
  • AppendAsync produces events at versions 1, 2, 3, …
  • AppendAsync advances stream.Version
  • AppendSnapshotAsync advances stream.Version
  • ListAsync(2, …) returns the second event after two appends
• All existing Papst test projects green (InMemory 7, EventStore 54, CodeGeneration 20, MongoDB 10, AzureCosmos 9)
• Verified against AltensoSCM's integration suite — incremental aggregation now correctly applies post-first-append events

[MPapst]

LGTM