The brief-lock exact-G capture + PK-range paging + structural fingerprint (C2 Task 5, design Ch1 — THE linchpin).

A ChunkReader owns a Capstan.Query connection and, per chunk of a snapshot table T, captures the chunk rows paired with an exact GTID position G that is a provable lower bound on the chunk's read view for T. That pairing is the correctness property the whole snapshot rests on: a lock-free @@gtid_executed read LEADS InnoDB row-visibility under concurrent commit (probe-confirmed: 300000/300000 under 3 writers), so a bare read would let a stale chunk row overwrite a fresh streamed row — silent corruption. A brief LOCK TABLES … READ quiesces T's writes while G and a START TRANSACTION WITH CONSISTENT SNAPSHOT view are captured together, making G exact.

The pinned capture sequence (design § Pinned decisions #2)

Per chunk of T from cursor, EXACTLY:

(i)   SET SESSION lock_wait_timeout = <bounded>   -- MDL default ~1yr; a bound turns a
                                                  --   contended lock into a HALT, not a wedge
(ii)  LOCK TABLES `T` READ                        -- waits for in-flight T-writes, blocks new ones
(iii) G = SELECT @@global.gtid_executed           -- EXACT: every T-txn <= G is committed AND visible
(iv)  START TRANSACTION WITH CONSISTENT SNAPSHOT   -- pins the read view V; for T, V == state as-of G
(v)   UNLOCK TABLES                                -- release; the pinned view V survives the unlock
(vi)  SELECT <projected cols> FROM `T`             -- as-of V, lock-free
        WHERE pk > cursor ORDER BY pk LIMIT chunk_size + 1   -- +1 = finality look-ahead
(vii) COMMIT

Step (iii) uses @@global.gtid_executed; gtid_executed is a global-scoped variable, so @@global.gtid_executed and the pinned decision's shorthand @@gtid_executed read the same value. The projection is EXPLICIT (never SELECT *) so the chunk carries the full row image and the per-chunk fingerprint is well-defined.

Halts (value-free atoms; design § Preconditions)

Faults are classified POSITIONALLY, by which phase of the pinned sequence failed — this is how the reader honours the Task-4 forward-finding that Capstan.Query.query/2 scrubs the MySQL error CODE (so a lock-wait timeout 1205 and a chunk-read fault both return the same value-free atom and cannot be told apart from the return value alone). The statement that failed is the distinct signal instead:

• :snapshot_lock_unavailable — a fault while ACQUIRING the lock: the bounding SET SESSION lock_wait_timeout or the LOCK TABLES … READ itself. A lock-wait timeout (bounded by step (i)) and a missing LOCK TABLES privilege both surface here — both are "could not obtain the lock". Budgeted, then halts.
• :snapshot_chunk_read_failed — a fault ONCE THE LOCK IS HELD or the view is being read: SELECT @@global.gtid_executed, START TRANSACTION WITH CONSISTENT SNAPSHOT, UNLOCK TABLES, the chunk SELECT, or COMMIT. The chunk SELECT is the canonical case; the surrounding view statements share its fate (the chunk could not be read consistently). Budgeted, then halts.
• :snapshot_schema_drifted — the per-chunk structural fingerprint changed from the baseline (an in-flight DDL). PERMANENT (a drifted schema does not un-drift on retry), so it halts immediately without spending the budget. (The other drift arm — an observed %Capstan.SchemaChange{} on the table — is the coordinator's, Task 8; the reader owns the fingerprint arm.)

Budgeted faults reuse Capstan.CheckpointStore.retry_decision/2 — the shared counter, never re-derived — so retry semantics cannot drift from C1. Permanence is classified POSITIONALLY, not via CheckpointStore.permanent_reason?/1: that helper only recognizes a store-config fault (:config_invalid) and would misclassify a code-scrubbed reader fault, so schema drift is marked permanent by construction (check_fingerprint/1 returns {:permanent, _} directly) and every lock/read fault is budgeted. The reader retries the whole capture on its OWN connection; it does NOT reconnect (a reconnect re-verifies source identity, Ch8, and is the coordinator's lifecycle concern) — a dead connection burns the budget and halts fail-closed, which the coordinator then propagates.

Rule 1 (design § Rule 1, tripwire 13)

The cursor is a row VALUE embedded as a SQL literal in WHERE pk > <cursor>. On a :snapshot_chunk_read_failed the failing SQL is NEVER logged or returned: Capstan.Query never logs SQL and returns a value-free atom, and this module maps faults to bare atoms and discards every raw fault term — so the cursor appears in no log, error, or crash report. The produced %Capstan.Snapshot.Chunk{} derives a value-eliding Inspect (rows/max_pk are never rendered). No row value or cursor is ever logged or telemetered here.