Postgres truncate can delete a concurrently appended file

[Dandandan]

Problem

At commit 3b914e4e26eadd7f74ec0862ee0113ba7368c780, the PostgreSQL writer serializes catalog commits correctly, but commit_truncate ignores its begin-time base_snapshot and retires every file live at commit time.

A truncate/replace that began before a concurrent append can therefore delete the newly appended file after it acquires the catalog row lock. This violates snapshot-isolation expectations: the stale writer should conflict with the change committed since its base snapshot rather than silently removing it.

Expected behavior

• Capture and validate the truncate writer's base snapshot under the catalog transaction lock.
• If files became live after that snapshot, return the existing typed conflict error.
• Do not auto-retry stale full-table replacement payloads.

Regression

Add a two-session PostgreSQL test with this order:

1. Begin truncate/replace from snapshot N.
2. Commit an append at snapshot N+1.
3. Attempt to commit the stale truncate.
4. Assert the truncate conflicts and the appended rows/files remain visible.

Related concurrency fix: #146 / #147.