[source-redshift] StackOverflowError in Amazon JDBC PGTimestamp reading timestamptz columns (regression in 0.5.5)

### Connector Name

source-redshift

### Connector Version

0.5.5

### What step the error happened?

During the sync

### Relevant information

After `source-redshift` auto-upgraded from `0.5.4` to `0.5.5`, every sync of a stream containing a `timestamp with time zone` (timestamptz) column fails immediately with a `java.lang.StackOverflowError` originating in the Amazon Redshift JDBC driver's `PGTimestamp` formatting (`getPostgresqlString` ↔ `toString` mutual recursion). The connection synced cleanly for months on `0.5.4` and broke on the first run after the `0.5.5` rollout. Streams on the **same** Redshift source that have no timestamptz column are unaffected.

This points at the only behavioral change in 0.5.5 — PR #74769 (https://github.com/airbytehq/airbyte/pull/74769), *"handle timezone-aware timestamps in cursor parsing and fix DST offset in `timestamptz` reads."*

**Environment**

- Connector: `source-redshift:0.5.5` (regressed from `0.5.4`)
- Deployment: Airbyte Cloud
- Sync mode: Full refresh (generated read is `SELECT ... FROM "".""` with no filter)
- Destination: irrelevant — fails before any record is emitted (`recordsEmitted: 0`)

**Minimal stream schema that reproduces**

```
column type
-------------------- ------------------------
id character varying
... (non-temporal columns omitted)
event_ts timestamp with time zone <-- trigger
unix_ts bigint <-- epoch equivalent, not affected
```

A stream whose schema contains no `timestamp with time zone` column syncs fine on the same source/version.

**Steps to reproduce**

1. Redshift source on `source-redshift:0.5.5`.
2. A table with a `timestamp with time zone` column, full-refresh.
3. Run the sync. The read fails with the `StackOverflowError` (see log output) before emitting any records.

**Expected behavior**

`timestamptz` columns read successfully, as they did on `0.5.4`.

**Actual behavior**

`StackOverflowError` in `PGTimestamp` on the first row; sync fails with 0 records. All retry attempts fail identically — deterministic, not transient.

**Suspected cause**

PR #74769, merged `2026-06-04T13:31:12Z`, is the only change in 0.5.5 and is specifically about timestamptz/DST read handling. It appears to route timestamptz values through a driver code path (`TimestampTz.getAdjustedTimestamp` → `PGTimestamp.getPostgresqlString`/`toString`) that recurses infinitely. The merge time lines up tightly with onset: the last successful sync on this connection was ~2h before the merge and the first failure ~1h after it. Reverting to `0.5.4` avoids the issue. Possibly resolvable by changing the bundled Amazon Redshift JDBC driver version, or by not invoking `PGTimestamp.toString()` during value extraction.

**Additional context**

- Source data is sound: ~1.17M rows, all `event_ts` values within 1900–2100, zero NULLs.
- Worked on `0.5.4`; first failure was the first run after the `0.5.5` rollout.
- Affects only streams that include a `timestamp with time zone` column; sibling streams without one continue to sync.

### Relevant log output

```shell
failureOrigin: "source"
failureType: "system_error"
internalMessage: "java.lang.StackOverflowError"
connector_command: "read"
recordsEmitted: 0

java.lang.StackOverflowError
at java.base/sun.util.calendar.BaseCalendar.getCalendarDateFromFixedDate(BaseCalendar.java:432)
at java.base/java.util.GregorianCalendar.computeFields(GregorianCalendar.java:2369)
at java.base/java.util.GregorianCalendar.computeFields(GregorianCalendar.java:2284)
at java.base/java.util.Calendar.setTimeInMillis(Calendar.java:1836)
at java.base/java.util.Calendar$Builder.build(Calendar.java:1520)
at java.base/sun.util.locale.provider.CalendarProviderImpl.getInstance(CalendarProviderImpl.java:87)
at java.base/java.util.Calendar.createCalendar(Calendar.java:1700)
at java.base/java.util.Calendar.getInstance(Calendar.java:1630)
at com.amazon.dsi.dataengine.utilities.TimestampTz.getAdjustedTimestamp(Unknown Source)
at com.amazon.redshift.api.PGTimestamp.getPostgresqlString(Unknown Source)
at com.amazon.redshift.api.PGTimestamp.toString(Unknown Source)
at com.amazon.redshift.api.PGTimestamp.getPostgresqlString(Unknown Source)
at com.amazon.redshift.api.PGTimestamp.toString(Unknown Source)
... (getPostgresqlString/toString repeat until the stack overflows)
```

### Contribute

- [ ] Yes, I want to contribute

---
**Internal Tracking:** https://github.com/airbytehq/oncall/issues/12808