issues/6124: feat(postgres-cdc): configurable batch + memory_backpressure - #6847

…sure

crates/feldera-types/src/transport/postgres.rs — added PostgresCdcBatchConfig (max_fill_ms, memory_budget_ratio, max_bytes) and PostgresCdcMemoryBackpressureConfig (activate_threshold, resume_threshold), each mirroring etl's own field shapes/defaults, with their own validate(). Wired into PostgresCdcReaderConfig as two new #[serde(default)] fields, so both are fully optional and back-compatible. 15 tests (up from 5).

crates/adapters/src/integrated/postgres/cdc_input.rs — replaced the hardcoded BatchConfig::default() / MemoryBackpressureConfig::default() in PipelineConfig construction with values derived from the connector config, via two small conversion functions. 4 new tests (55 total, up from 51).

Two connector-validation paths exist in this codebase, and they run at very different points in the user's workflow:

1. Rust-side (crates/feldera-types/src/transport/postgres.rs:189, called from cdc_input.rs:63) — only runs when the connector actually starts, i.e. after a pipeline is deployed and Feldera tries to connect and begin replication. That's a slow feedback loop: write SQL → deploy pipeline → wait for connector startup → get an error string back.
2. Java-side (ConnectorValidator.java → each config class's validate(), e.g. PostgresCdcReaderConfig.validate()) — runs during SQL compilation of the CREATE TABLE ... WITH ('connectors' = ...) statement, before anything is ever deployed. It's also able to map the bad field back to its exact line/column in the original SQL source (via the JSON-pointer → source-position machinery in ConfigReporter), so the user gets a precise inline warning instead of an opaque runtime error.

Every other connector in this file already follows that pattern (Kafka, S3, Nats, the plain Postgres reader/writer, etc.) — each has matching validation logic on both sides. Mihai's point was that this PR added new fields (batch, memory_backpressure) with range checks only on the Rust runtime side, so a user with e.g. resume_threshold >= activate_threshold wouldn't find out until they deploy and the connector fails to start, instead of getting a compile-time warning immediately. Duplicating the checks closes that gap and keeps the new fields consistent with how the rest of the connector configs behave.