InMemoryEventStore: standalone-stream resume broken by getStreamIdFromEventId split

InMemoryEventStore.getStreamIdFromEventId derives the stream id with eventId.split('_')[0], which returns the empty string for any event id belonging to the standalone GET stream (its stream id _GET_stream starts with an underscore, so generated ids look like _GET_stream_<uuid>).

As a result, resuming the standalone stream with a Last-Event-ID never works with the shipped example store: replayEventsAfter replays nothing and returns '', and the transport registers the successor stream under the key '' instead of _GET_stream. All stored and future standalone notifications are then silently dropped while the client sits on a healthy-looking keep-alive'd stream.

Pre-existing (the id format and the split predate the keep-alive work). Fix is to derive the stream id from the last separator instead of the first, or to keep an explicit eventId-to-streamId map in the store. Affects the example store on both main and v1.x; regression tests built on this store also exercise the wrong key.

Start by locating InMemoryEventStore and its getStreamIdFromEventId and replayEventsAfter methods. Run the regression tests built on this example store, then verify that resuming the standalone GET stream replays stored events, registers the successor under _GET_stream, and delivers future notifications.