docs(api2): interleaved SQLite commits may violate single-round-trip consistency

As previously discussed with @legoktm:  v2 Journalist API event-handlers
reuse utility functions that are are inconsistent in when they
session.commit() and/or session.refresh().  The event-handlers
themselves inherit these inconsistent transaction boundaries.

On the one hand, this is too bad.  We'd like event-handlers to be
(approximately) pure functions on the received event data and the
current server state, but in practice they're as fuzzy as our
transaction isolation.  We could eliminate these intra-event races by
constructing a session for each event-handler invocation, returning only
values read within that session, and committing its changes explicitly.

On the other hand, I don't actually think this is worth fixing.  *Either
way*---with or without strict per-event isolation---a server that
receives events from multiple clients close enough together will wind up
signalling those clients to sync again in order to catch up to one
another's writes.  Eventual convergence is good enough in both cases, so
let's just document explicitly that this is an expected exception to
single-round-trip consistency.

Author: cfm

API2.md

@@ -233,8 +233,18 @@ E_n\}$; and
 
 4. $C$'s index SHOULD match $S$'s index without a subsequent synchronization.
 
-This property does not hold for resubmitted events (returning HTTP `208 Already
-Reported)`. A subsequent synchronization MAY be necessary for the client to
+This property does not hold:
+
+- when the server has multiple active clients. Because this API reuses some
+  utility functions from the v1 Journalist API, it inherits the inconsistent
+  transaction isolation of the latter's use of a shared SQLAlchemy session, which
+  may cause side effects of events received very close in time to be interleaved
+  at the SQLite level.
+
+- for resubmitted events, which return an HTTP `208 Already Reported` status
+  without the full result of the event.
+
+In these cases, a subsequent synchronization MAY be necessary for the client to
 "catch up" to the effects of accepted events.
 
 #### Snowflake IDs