[INF-1722] Accept absent primary-key deletes during replay

[thesyncim]

Ticket

https://linear.app/stream/issue/INF-1722/migrate-dublinc3

Summary

Treat a source DELETE as a no-op when its catalog-validated primary key is already absent on the target. This unblocks replay without skipping the source transaction or resetting migration progress.

Only DELETE result validation changes. Malformed identities, duplicate/invalid result ordinals, excess matches, unsafe identities, SQL errors, and receipt/checkpoint guards remain errors. No configuration, SQL generation, claim format, acknowledgement, or UPDATE behavior changes.

Validation

• Reproduced the v68 failure for single, VALUES, array, typed-stage and composite-key DELETEs on PostgreSQL 16/17/18; the fix passes those cases.
• Real pgoutput capture/recovery, missing DELETE followed by same-key INSERT, transaction rollback, and legacy/current claim crash-resume with exact progress counters.
• Full unit/race suite, go vet ./..., and complete CDC/application integration suites with the race detector pass; CI is green.
• Exact v68→candidate image rehearsal passes: same snapshot/config hashes, source slot and checkpoint; normal resume processes 32 transactions / 64 changes with exact source/target counts and row digests. No recopy or checkpoint edits.

Checklist

• Regression tests cover the changed behavior and retained safety checks.
• README documents the exception; no API changes.

Rollout / risk

Image-only update followed by normal resume on the existing state directory, source slot and target checkpoint. No recopy, checkpoint skip, production source row writes, or cutover. An old binary can still open the unchanged state format, but may stop again on an absent DELETE. This does not authorize independent target traffic or prove absence of unrelated drift.