Backend crashes on DDL statements longer than ~1100 bytes (self-compiled 2.1.8, PG 17.10)

## Summary

On a self-compiled pgactive 2.1.8 node, **any DDL statement whose text exceeds roughly 1100 bytes crashes the backend**. The connection is closed (`server closed the connection unexpectedly`), the postmaster survives, and **nothing is logged by the server**.

The content of the statement is irrelevant — only its **length** matters.

## Reproduction

On a database with the `pgactive` extension installed, as a superuser:

```sql
-- passes
CREATE OR REPLACE FUNCTION public.t() RETURNS int LANGUAGE plpgsql AS $f$
BEGIN
-- <1000 'x' characters>
RETURN 1;
END; $f$;

-- crashes the backend
CREATE OR REPLACE FUNCTION public.t() RETURNS int LANGUAGE plpgsql AS $f$
BEGIN
-- <1100 'x' characters>
RETURN 1;
END; $f$;
```

The function body is meaningless on purpose: a comment is enough to trigger it. Measured threshold: **1080 bytes passes, 1100 bytes crashes** (total statement length). The boundary is not sharp, which is what one would expect from a memory overflow.

## What it is not

Verified by elimination:

| Hypothesis | Result |
|---|---|
| Specific SQL construct (CTEs, `NOT EXISTS`, `LEFT JOIN`, `SELECT *`, function calls) | ruled out — each passes on its own |
| `CREATE OR REPLACE` of an existing object | ruled out — crashes with a brand-new name too |
| plpgsql body validation | ruled out — `SET check_function_bodies = off` changes nothing |
| Client library | ruled out — same crash from `psql` and from psycopg2 |
| Language | happens with both `LANGUAGE sql` and `LANGUAGE plpgsql` |
| Schema qualification of referenced tables | irrelevant |

The only pgactive event trigger present is `pgactive_truncate_trigger_add` (`evtenabled = 'A'`). Reading `src/pgactive_ddlrep_truncate.c`, that handler returns early for anything that is not `CREATE TABLE`, so the crash likely happens elsewhere in the DDL path.

## Environment

| | Affected node | Unaffected |
|---|---|---|
| pgactive | **2.1.8** | **2.1.8** (RDS) |
| PostgreSQL | 17.10 | 17.10 |
| OS / build | Debian bookworm, built from source (`./configure && make`, no extra flags), `postgres:17.10-bookworm` image | Amazon RDS binary |

Same extension version and same PostgreSQL version on both sides — **only the build differs**. A third database without pgactive accepts the identical DDL without problems.

`pgactive.skip_ddl_replication = on` on the affected node.

## Impact

Any schema migration containing a moderately large DDL statement — a function with a non-trivial body, a wide `CREATE TABLE`, a complex view — fails on the node. Because the failure surfaces as a dropped connection with no server-side log entry, the length limit is very hard to guess: it took us several hours and a bisection on statement size to find it.

Transactions roll back cleanly, so no corruption was observed.

## Notes

Happy to provide more detail, run additional tests on the affected node, or try a build with different compiler flags if that would help narrow it down.