Fix busted anchor link

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](#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, 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.
 
 ### Parallel Commits