Incremental snapshots with debezium 3.2 against postgres aurora doesn't work as expected [DBZ-9498]

Migrated from [DBZ-9498](https://issues.redhat.com/browse/DBZ-9498)

In order to make your issue reports as actionable as possible, please provide the following information, depending on the issue type.
h1. Bug report

For bug reports, provide this information, please:
h2. What Debezium connector do you use and what version?

io.debezium.connector.postgresql.PostgresConnector
version: 3.2
h2. What is the connector configuration?

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaConnector
metadata:
name: debezium-connector-olpqa-discard-test
namespace: colp-loadenv
labels:
strimzi.io/cluster: kafka-connect-dba-colp
spec:
class: io.debezium.connector.postgresql.PostgresConnector
tasksMax: 1
config:
tasks.max: 1
# Full load on first run, then CDC
snapshot.mode: configuration_based
snapshot.mode.configuration.based.snapshot.schema: true
snapshot.mode.configuration.based.snapshot.data: false
snapshot.mode.configuration.based.start.stream: true
#incremental.snapshot.enabled: true
incremental.snapshot.chunk.size: 10000
snapshot.fetch.size: 20000
snapshot.max.threads: 3

#Debezium Engine/Queing Settings
max.batch.size: 8192
max.queue.size: 65536
max.queue.size.in.bytes: 536870912#512MB
 
# Schema refresh for DDL changes
schema.refresh.interval.ms: 10000
 
# Capture DDL events
include.schema.changes: true
plugin.name: pgoutput
publication.name: app_pub
database.hostname: dbhost
database.port: 5432
database.user: ${secrets:dba-debezium/colp-dba-secret:username}
database.password: ${secrets:dba-debezium/colp-dba-secret:password}
database.dbname: olpqa-db-aurora
publish.via.partition.root: true
topic.prefix: olpqa-discard-test
topic.creation.enable: true
topic.creation.default.replication.factor: -1
topic.creation.default.partitions: -1
topic.creation.default.retention.ms: 1209600000
topic.creation.default.max.message.bytes: 4194304
schema.include.list: discard
table.include.list: discard.orders,discard.order_items
# Replication slot configuration
slot.name: app_pub
 
# keep failing on real errors
errors.tolerance: none
# be more patient with transient failures (incl. SR connect failures)
errors.retry.timeout: 600000# 10m total retry budget (pick your SLO)
errors.retry.delay.max.ms: 30000# backoff cap between retries (e.g., 30s)
# optional: better logs while it retries
errors.log.enable: true
errors.log.include.messages: true

# Signal configuration for incremental snapshots
signal.kafka.bootstrap.servers: boot-mn3.stagemskexpresscluste.881mqu.c16.kafka.us-east-1.amazonaws.com:9096,boot-fsk.stagemskexpresscluste.881mqu.c16.kafka.us-east-1.amazonaws.com:9096,boot-avg.stagemskexpresscluste.881mqu.c16.kafka.us-east-1.amazonaws.com:9096
signal.kafka.topic: olpqa-discard.signal
signal.enabled.channels: source,kafka
signal.data.collection: discard.debezium_discard_configbased_signal
signal.consumer.security.protocol: SASL_SSL
signal.consumer.sasl.mechanism: SCRAM-SHA-512
signal.consumer.sasl.jaas.config: org.apache.kafka.common.security.scram.ScramLoginModule required username=cdo password=${secrets:dba-debezium/msk-secret-kafka:kafka-connect-msk-password};
signal.producer.security.protocol: SASL_SSL
signal.producer.sasl.mechanism: SCRAM-SHA-512
signal.producer.sasl.jaas.config: org.apache.kafka.common.security.scram.ScramLoginModule required username=cdo password=${secrets:dba-debezium/msk-secret-kafka:kafka-connect-msk-password};
h2. What is the captured database version and mode of deployment?

(E.g. on-premises, with a specific cloud provider, etc.)

Aurora postgres "16.6.3"
h2. What behavior do you expect?

We want the incremental snapshot to start by inserting a record into the source table or the signal topic. 
h2. What behavior do you see?

with Source: When we insert a record into the table, debezium doesn't even pick up the message and start the initial load:

INSERT INTO discard.debezium_discard_configbased_signal (id, type, data)
VALUES (
  'backfill-2025-09-23-01',
  'execute-snapshot',
  '

{"type":"incremental","data-collections":["discard.orders","discard.order_items"]}

'
);
 
With Kafka: When a message was published, we see the message gets picked up and inserts two rows in the the database signal table as:

"backfill-2025-09-23-01" "execute-snapshot" "

{""type"":""incremental"",""data-collections"":[""discard.orders"",""discard.order_items""]}

"
*"5ae7e50a-8d7f-4245-8042-62de5be72715-open" "snapshot-window-open" "\{""openWindowTimestamp"": ""2025-09-23T18:49:58.124690769Z""}"*
*"5ae7e50a-8d7f-4245-8042-62de5be72715-close" "snapshot-window-close" "\{""openWindowTimestamp"": ""2025-09-23T18:49:58.124690769Z"", ""closeWindowTimestamp"": ""2025-09-23T18:49:58.341435949Z""}"*
h2. Do you see the same behaviour using the latest released Debezium version?

We haven't tested with any other version as 3.2 seems the latest one.
h2. Do you have the connector logs, ideally from start till finish?

(You might be asked later to provide [DEBUG/TRACE|https://debezium.io/documentation/reference/stable/operations/logging.html] level log)

Yes.
h2. How to reproduce the issue using our [tutorial|https://github.com/debezium/debezium-examples/tree/main/tutorial] deployment?

h1. Feature request or enhancement

For feature requests or enhancements, provide this information, please:
h2. Which use case/requirement will be addressed by the proposed feature?

h2. Implementation ideas (optional)

Start with the provided PostgresConnector configuration, comparing the source and Kafka signal channels and reviewing the available connector logs. Reproduce the incremental snapshot request against Aurora PostgreSQL 16.6.3 and determine why the source signal is ignored and the Kafka path only creates signal-table rows; done means the requested incremental snapshot starts and processes both listed collections.

Written by the indexing model from the issue text.