Update with stevendanna feedback (1)

Specifically, revise the paragraph to simplify the language slightly,
and update the list of per-statement work to make sure parts of speech
agree.

Author: rmloveland

src/current/v25.4/architecture/transaction-layer.md

@@ -364,7 +364,7 @@ At a high level, transaction pipelining works as follows:
 
 In terms of the SQL snippet shown above, all of the waiting for write intents to propagate and be committed happens once, at the very end of the transaction, rather than for each individual write. This means the consensus-related waiting is not `O(n)` in the number of SQL DML statements; instead, it approaches `O(1)`.
 
-However, the overall client-observed latency still includes per-statement work that must be performed, so the overall transaction performance does not, in general, achieve `O(1)`. For example, although transaction pipelining parallelizes the [Raft]({% link {{ page.version.version }}/architecture/replication-layer.md %}#raft) consensus work for [intent writes](#write-intents) across statements, each statement must still be [planned and evaluated]({% link {{ page.version.version }}/architecture/sql-layer.md %}) (e.g., [index]({% link {{ page.version.version }}/indexes.md %}) lookups, [constraint]({% link {{ page.version.version }}/constraints.md %}) checks, [conflict](#transaction-conflicts) detection, and waiting on [contending]({% link {{ page.version.version }}/performance-best-practices-overview.md %}#understanding-and-avoiding-transaction-contention) writes). The client still submits statements sequentially. Statements that touch the same rows can also create pipeline stalls to preserve [read-your-writes](https://jepsen.io/consistency/models/read-your-writes) ordering. As a result, while the consensus component of write latency can approach `O(1)` with respect to the number of statements, end-to-end transaction latency can still increase with the number of statements.
+However, client-observed latency still includes a certain amount of per-statement work that must be performed. For example, although transaction pipelining parallelizes the [Raft]({% link {{ page.version.version }}/architecture/replication-layer.md %}#raft) consensus work for [intent writes](#write-intents) across statements, each statement must be [planned and evaluated]({% link {{ page.version.version }}/architecture/sql-layer.md %}). This includes scanning [indexes]({% link {{ page.version.version }}/indexes.md %}), checking [constraints]({% link {{ page.version.version }}/constraints.md %}), detecting [conflicts](#transaction-conflicts), and waiting on [contending writes]({% link {{ page.version.version }}/performance-best-practices-overview.md %}#understanding-and-avoiding-transaction-contention). The client still submits statements sequentially. Statements that touch the same rows can also create pipeline stalls to preserve [read-your-writes](https://jepsen.io/consistency/models/read-your-writes) ordering. As a result, while the consensus component of write latency can approach `O(1)` with respect to the number of statements, end-to-end transaction latency can still increase with the number of statements.
 
 ### Parallel Commits