resume scope: decide the source-side identity (endpoint field vs config fingerprint)

[hugocorreia90]

The resume scope (#1573, #1582) covers pipeline name, --filter, and TARGET routing. It records nothing about the source. A [source] edit between runs still skips silently.

Reproduce

1. Run a replication pipeline to success.
2. Edit its [source] block — point source.discovery.adapter at another adapter, or change schema_pattern so discovery maps different source tables onto the same target names.
3. rocky run --resume-latest after a failure. completed_keys matches the checkpoint's Success entries by TARGET key, so tables never copied from the new source are skipped and the run exits 0.

Same code path as the endpoint hole #1582 closes, one field short.

The decision

What defines "the same run"? Two candidate shapes:

• Add the discovery adapter's endpoint_identity() plus the schema pattern to ResumeTarget. Narrow, matches fix(engine): structure the resume scope and sweep checkpoints with run records #1582's pattern.
• Stamp the pipeline-block fingerprint that load_rocky_config_fingerprinted already computes, and refuse (or warn) on mismatch. Total, but refuses resume on ANY pipeline edit, harmless ones included.

Refusing more is fail-closed; refusing everything makes --resume-latest useless after any tweak. This is a contract call, not a patch.

Found by independent adversarial review (Codex) of #1582's branch; the reproduction was verified against the real code path before filing.

[hugocorreia90]

Related, from #1591 (which closes #1586).

A concrete trigger for this gap, found by independent red-team review:

• [source.schema_pattern] separator = "__", no [target] separator (so the target inherits it)
• catalog_template = "wh", schema_template = "raw__{regions}"
• the run uses --branch feature, so the target schema is always branch__feature

SchemaPattern::parse splits every source schema name on the pattern separator. Change it to "---" and src__acme__us_west__shopify stops parsing while src__acme---us_west---shopify starts. The catalog is static and the schema is the override, so the new source resolves to the same wh.branch__feature.orders key. A resume then skips a table it never copied.

#1591 blocks that specific path by never eliding a separator the target inherits from the pattern. That is a patch over one symptom, not the class:

• with an explicit [target] separator, editing [source.schema_pattern] separator is recorded nowhere and the resume still crosses;
• the pattern prefix and components are not in the scope at all.

The fix shape stays the one this issue names: put source-pattern identity in ResumeScope, derived from the same binding the run parses with.

[hugocorreia90]

Recording the decision: option C — keep the target routing already in the scope, and add source fields only if a named refusal message is wanted. Rejecting option B.

Why not B (a config fingerprint). Two facts kill it. It refuses on every credential rotation, because the fingerprint covers bytes that have nothing to do with where data lands. And when it does refuse it cannot say what changed — the operator gets a hash mismatch and no remedy. That is the opposite of the direction #1582 took with EndpointIdentity, which deliberately records location fields so the refusal can name them.

Why C is enough today. The hazard is two runs whose source set differs resolving to the same catalog.schema.table keys, so completed_keys skips a table the run never copied. The target routing already in the scope covers the target half. The source half is only reachable through the schema pattern, and #1591 already closed the separator case for it.

If a named refusal is wanted, option A's minimal form is cheap and the value is already at the seam: replication_resume_scope (run.rs) takes pattern: &SchemaPattern as a parameter and currently uses it only for the separator classification. Adding source.catalog plus the pattern's own shape would be a few lines, plus the pinned blob test.

Land it before the unreleased v23 blob ships, so there is one shape rather than two. That puts it alongside #1592 (PR #1600) and #1584, all before the next engine-v* tag.

What would flip this to A: a replication path that reads source data through the discovery adapter's own endpoint — an Iceberg or Airbyte host — rather than through the target warehouse. process_table shows no such path today; if one appears, the source endpoint becomes a location fact and belongs in the identity.

Decision made under the standing 'proceed on the recommended default' authority; say so and I will implement option A instead.

[hugocorreia90]

Grounding found while working #1584: two Snowflake shapes resolve a name against the session's default database, so nothing in the scope pins where the data actually is.

• Target: catalog_template may render empty, and Snowflake's format_table_ref then emits "schema"."table". With no adapter database, the write lands wherever the session's DEFAULT_NAMESPACE points.
• Source: [pipeline.<name>.source] catalog is optional, and an absent one becomes "", so the read is unqualified too.

The source half is exactly what this issue is deciding. Written up with the concrete resume trigger in #1611.