The bug in InMemoryEventStore break SSE stream resumability

Describe the bug
The standalong sse stream Id is coded to _GET_stream and the current InMemoryEventStore generate event Ids in the format -
${streamId}-${Date.now()}_${Math.random().toString(36).substring(2, 10)}

The replayEventsAfter(...) is called when client try to re-connect and resume the stream which further calls getStreamIdFromEventId(...) -

    // Extract the stream ID from the event ID
    const streamId = this.getStreamIdFromEventId(lastEventId);
    if (!streamId) {
      return '';
    }

The issue is that getStreamIdFromEventId(...) will always return an empty string as the streamId due to the current eventId format and the code will return from this if check.

To Reproduce
Steps to reproduce the behavior:

1. Create a tool with at least 2 elicitation requests.
2. Call the tool.
3. Try to reconnect with SSE stream - nothing will be returned.

Expected behavior
MCP client should be able to re-connect to SSE stream.

Fix
The fix could be to use a different delimiter than underscore when combining streamId with rest of the eventId.
Used dash("-") in below sample fix -

  /**
   * Generates a unique event ID for a given stream ID
   */
  private generateEventId(streamId: string): string {
--->    return `${streamId}**-**${Date.now()}_${Math.random().toString(36).substring(2, 10)}`;
  }

  /**
   * Extracts the stream ID from an event ID
   */
  private getStreamIdFromEventId(eventId: string): string {
--->    const parts = eventId.split('**-**');
    return parts.length > 0 ? parts[0] : '';
  }

Start in src/examples/shared/inMemoryEventStore.ts and compare generateEventId, getStreamIdFromEventId, and replayEventsAfter with the stream handling in src/server/streamableHttp.ts. Reproduce the two-elicitation reconnect scenario, then verify that the Last-Event-ID is parsed consistently and previously emitted events are returned when the SSE stream resumes.