docs: clarify async nature

Signed-off-by: Michael Adler <[email protected]>

docs/operations.md

@@ -144,11 +144,13 @@ See `wfxctl job events --help` for other filter parameters, e.g. workflow names.
 
 #### Considerations and Limitations
 
-1. **Asynchronous Job Status Updates**: Job status updates are sent asynchronously to avoid the risk of a subscriber
-   interfering with the actual job operation. As a result, messages could arrive in a not necessarily linear order,
-   deviating from the client's expectation of a naturally ordered flow of events. While this is generally not a concern,
+1. **Asynchronous Job Status Updates**: Job status updates are dispatched asynchronously to avoid the risk of a subscriber
+   interfering with the actual job operation. In particular, there is no guarantee that the messages sent to the client
+   arrive in a linear order (another reason for that may networking-related). While this is typically not a concern,
    it could become an issue in high-concurrency situations. For example, when multiple clients try to modify the same
-   job or when a single client issues a rapid sequence of status updates.
+   job or when a single client issues a rapid sequence of status updates. As a result, messages could arrive in a not
+   necessarily linear order, deviating from the client's expectation. However, the client can use the (event) `id` and
+   `ctime` fields to establish a natural ordering of events.
 2. **Unacknowledged Server-Sent Events (SSE)**: SSE operates on a one-way communication model and does not include an
    acknowledgment or handshake protocol to confirm message delivery. This design choice aligns with the fundamental
    principles of SSE but does mean that there's a possibility some events may not reach the intended subscriber (which