SS-489 - test: cover MySQL exports progressing during a held snapshot - #40208

…#40206)

### Motivation

Today a MySQL source snapshots all of its tables before it reads any of
the binlog. This PR lets the replication operator read the binlog while
the snapshot runs, as #39419 did for PostgreSQL. #40207 then lets each
export's frontier advance on its own.

NOTE: this needs an exception added for the 2s increase in snapshot
performance, but I can't add it until I have a merge hash from main.
Will do in a follow up PR.

Closes: [SS-488](https://linear.app/materializeinc/issue/SS-488)

### Description

All new behavior is keyed off
`storage_persist_sink_description_lookahead` being nonzero. This is the
same switch PostgreSQL uses.

With a nonzero lookahead, the snapshot operator emits its rewind
requests as soon as the snapshot GTID frontier is known. That happens
before any table is read. The replication operator then reads the binlog
while the tables are read. Every export still advances together.
Replication data is staged in the dataflow until the snapshot completes.

With the lookahead at zero, rewinds are emitted after the snapshot
completes, as before.

The snapshot operator reads the setting once at render time. That
matches the value the persist sink reads in the same dataflow build.

MySQL sources now count as OLTP sources in `render.rs`. A snapshotting
MySQL export therefore gets the persist sink's snapshot ceiling and
lookahead grouping, like a PostgreSQL export. The mzcompose default sets
the lookahead to 2s. The MySQL initial load feature benchmarks should
see their first rows about that much later, as the PgCdc benchmarks did
after #39602.

#39419 also added a leader check that the replication slot exists before
the snapshot starts. MySQL needs no counterpart. The replication
operator already checks `@@gtid_purged` against the resume upper before
it waits for rewind requests.

### Verification

The mzcompose default sets the lookahead, so the existing
mzcompose-based MySQL source tests exercise the early rewind path.
#40208 adds targeted coverage.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

---------

Co-authored-by: Claude <[email protected]>

…napshot (#40207)

### Motivation

Every export's frontier stays at the minimum until the last table's
snapshot read finishes. Adding one large table to a MySQL source
therefore still stalls ingestion for every table already hydrated in
that source. #39479 fixed the same problem for PostgreSQL.

### Description

With `storage_persist_sink_description_lookahead` nonzero, each export's
port holds the minimum capability only while that export still has
snapshot data to emit or a pending rewind.

- Exports that are not being snapshotted drop their snapshot
capabilities up front. They advance with the binlog.
- After a worker plans its reads, it drops the ports of exports it reads
no part of. This also covers exports that failed schema verification.
- A snapshotted export releases its snapshot capability on each worker
as soon as that worker finishes reading its table.
- The replication operator downgrades every port without a pending
rewind at each yield point.

With the lookahead at zero, all ports advance together. Behavior then
matches #40206.

The replication operator now reads the setting at render time as well.
Both operators read it in the same dataflow build and agree with the
persist sink.

### Verification

The mzcompose default sets the lookahead, so the existing
mzcompose-based MySQL source tests exercise per-export progress. #40208
adds targeted coverage.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-authored-by: Claude <[email protected]>