fix: clear the target chunk when the copy goes through the hypertable

[alejandrodnm]

When the source chunk is partial and the target chunk isn't, copy_chunk writes the uncompressed rows through the hypertable instead of into the chunk, because setting a chunk's status to partial needs a permission tsdbadmin doesn't have. The delete meant to clear the range followed the copy to the hypertable, and DELETE FROM ONLY <hypertable> clears nothing: a hypertable keeps every row in its chunks, so its own heap is always empty. On that path the copy adds to whatever the chunk already held.

It stays invisible while the branch is only reached on a first copy, where the chunk is empty anyway. Writing the rows through the hypertable makes the chunk partial, so a second copy takes the other branch and deletes normally. But anything that folds those rows back into compressed form, which is what a compression policy does, clears the partial status and puts a second copy back on this branch with data already in place, and the target ends up with twice the rows.

The delete and the cagg invalidation trigger now act on the chunk, the relation that ends up holding the rows, while the copy still goes wherever the caller needs it. That also restores the assumption #206 relies on: from TimescaleDB 2.23 the delete that clears a chunk's uncompressed rows removes its compressed batches too, which only holds if that delete reaches the chunk in the first place.

Stacked on #206, review that one first.

https://claude.ai/code/session_01DMDRhYXfUK4WpAD6zUfeaW