Postgres Server Crash When Cancelling Copy Statement

### What happens?

When cancelling a copy statement postgres crash occurred. Not sure how to reproduce but just wanted to file the issue.

```
2025-11-17 20:04:33.834 GMT [1060959] [unknown]@[unknown] LOG: connection received: host=[local]
terminate called after throwing an instance of 'duckdb::Exception'
what(): {"exception_type":"Executor","exception_message":"(PGDuckDB/Cleanup) another command is already in progress"}
2025-11-17 20:04:47.737 GMT [1050525] LOG: server process (PID 1060932) was terminated by signal 6: Aborted
2025-11-17 20:04:47.737 GMT [1050525] DETAIL: Failed process was running:
COPY schema_name.table_name
TO 's3://bucket-name/file_name';

2025-11-17 20:04:47.737 GMT [1050525] LOG: terminating any other active server processes
2025-11-17 20:04:47.757 GMT [1050525] LOG: all server processes terminated; reinitializing
2025-11-17 20:04:49.258 GMT [1061012] LOG: database system was interrupted; last known up at 2025-11-17 19:59:50 GMT
2025-11-17 20:04:49.495 GMT [1061012] LOG: database system was not properly shut down; automatic recovery in progress
2025-11-17 20:04:49.496 GMT [1061012] LOG: redo starts at 0/20F573C0
2025-11-17 20:04:49.496 GMT [1061012] LOG: invalid record length at 0/20F58C40: wanted 24, got 0
2025-11-17 20:04:49.496 GMT [1061012] LOG: redo done at 0/20F58C08 system usage: CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s
2025-11-17 20:04:49.550 GMT [1050525] LOG: database system is ready to accept connections

```

### To Reproduce

I'm not sure how to reproduce at the moment

### OS:

Linux

### pg_duckdb Version (if built from source use commit hash):

v1.0.0

### Postgres Version (if built from source use commit hash):

14.19

### Hardware:

_No response_

### Full Name:

Andrew Jackson

### Affiliation:

Andrew Jackson

### What is the latest build you tested with? If possible, we recommend testing with the latest nightly build.

I have tested with a stable release

### Did you include all relevant data sets for reproducing the issue?

No - Other reason (please specify in the issue body)

### Did you include all code required to reproduce the issue?

- [ ] Yes, I have

### Did you include all relevant configuration (e.g., CPU architecture, Linux distribution) to reproduce the issue?

- [ ] Yes, I have

Start by investigating cancellation of the COPY schema_name.table_name TO 's3://bucket-name/file_name' entry point on Linux with pg_duckdb v1.0.0 and PostgreSQL 14.19. Work toward a reliable reproduction of the reported abort and verify that cancelling the COPY no longer crashes or leaves the server needing recovery.

Written by the indexing model from the issue text.