storeEvent in EventStore Receives Hardcoded `streamId`

Describe the bug

I'm writing an EventStore using Redis. There can be several users, whose data must be seperate. But since streamId is sometimes hardcoded as _GET_stream, I can't distinguish the users in storeEvent. If I do something like the one in InMemoryEventStore, I think all users will be able to read the same stream (_GET_stream)

To Reproduce

Steps to reproduce the behavior:

1. Add a console.log to storeEvent method of InMemoryEventStore

async storeEvent(streamId: string, message: JSONRPCMessage): Promise<string> {
  const eventId = this.generateEventId(streamId);
  console.log(streamId, eventId);
  
  this.events.set(eventId, { streamId, message });
  return eventId;
}

2. Start server at src/examples/server/simpleStreamableHttp.ts
3. Start client at src/examples/client/simpleStreamableHttp.ts
4. In the client, run multi-greet hey
5. Check the logs of the server:

_GET_stream _GET_stream_1759497356533_y5aw8vh7
_GET_stream _GET_stream_1759497357535_3hvrf2jx
_GET_stream _GET_stream_1759497358537_5pb6ci89

streamId is _GET_stream in each one. Yes, eventId makes it possible to differenciate them. In replayEventsAfter, these events are sorted and returned after the lastEventId. But now imagine that this is in production and this.events is a list or stream on Redis. All users get the same streamId in storeEvent. There is no way to differentiate their streams.

Expected behavior

There should be a way to differentiate users in storeEvent, instead of getting the same streamId.

Start with src/server/streamableHttp.ts, especially storeEvent, replayEventsAfter, and the streamId call sites, then compare src/examples/shared/inMemoryEventStore.ts and the simpleStreamableHttp server and client examples. Reproduce the multi-greet request and trace how stream IDs are assigned. Done means an EventStore can distinguish independent users and replay only the appropriate events without breaking the existing examples.