fix(api): StreamsBroadcastChannel start reading messages from the end (#34030)

The current frontend implementation closes the connection once `workflow_paused` SSE event is received and establish a new connection to subscribe new events. The implementation of `StreamsBroadcastChannel` sets initial `_last_id` to `0-0`, consumes streams from start and send `workflow_paused` event created before pauses to frontend, causing excessive connections being established. 

This PR fixes the issue by setting initial id to `$`, which means only new messages are received by the subscription.

api/libs/broadcast_channel/channel.py

@@ -125,7 +125,8 @@ class BroadcastChannel(Protocol):
     a specific topic, all subscription should receive the published message.
 
     There are no restriction for the persistence of messages. Once a subscription is created, it
-    should receive all subsequent messages published.
+    should receive all subsequent messages published. However, a subscription should not receive
+    any message published before the subscription is established.
 
     `BroadcastChannel` implementations must be thread-safe and support concurrent use by multiple threads.
     """

api/libs/broadcast_channel/redis/streams_channel.py

@@ -64,7 +64,10 @@ class _StreamsSubscription(Subscription):
         self._client = client
         self._key = key
         self._closed = threading.Event()
-        self._last_id = "0-0"
+        # Setting initial last id to `$` to signal redis that we only want new messages.
+        #
+        # ref: https://redis.io/docs/latest/commands/xread/#the-special--id
+        self._last_id = "$"
         self._queue: queue.Queue[object] = queue.Queue()
         self._start_lock = threading.Lock()
         self._listener: threading.Thread | None = None