adapter: buffer a transaction's blind read-then-write until commit

[aljoscha]

Motivation

Part 7 of 7 in a stack that moves DELETE, UPDATE and INSERT ... SELECT
off the coordinator onto the session task, using optimistic concurrency
control. Design doc:
20260210_incremental_occ_read_then_write.md
(lands in part 6).

Part 6 refuses a read-then-write inside a multi-statement transaction, because
a write that commits immediately cannot be rolled back at transaction end.
That is the right answer only for a write that reads persisted state.

Closes SQL-593

Description

A write whose selection reads nothing produces diffs that are valid at any
timestamp, so it can be buffered as a session write op and land with the rest
of the transaction, which is what a constant INSERT already does.

Two predicates decide this and they have to agree. Before planning, a
syntactic one on depends_on() refuses a read-dependent write while refusing
is still possible. During execution the subscribe answers the same question
dynamically, and the loop's Committed arm asserts it has no write timestamp
to apply inside a transaction, which is that disagreement made observable. It
is a soft assertion because the write is already durable by then.

Separately: max_concurrent_occ_writes is sampled once at startup, so ALTER SYSTEM SET on it silently did nothing. The statement is still accepted, and
now warns that the change takes effect when environmentd restarts. RESET ALL
names every parameter rather than one, so it compares values instead of names.
The parameter also gets a domain constraint of at least 1, since zero permits
would leave every read-then-write waiting out its statement_timeout.

Verification

Tests for a non-constant INSERT in a transaction being buffered and
committing with the transaction, for a read-dependent write in a transaction
being refused, for a read-only transaction, and for the startup-only variable
warning on SET, RESET and RESET ALL.

[linear-code]

SQL-593