pg_lake_table: fix vacuum compaction summary logging under autovacuum

[darshil929]

Description

The compaction summary introduced in #350 runs after the compaction loop has already rotated into a fresh transaction, so no snapshot is active at that point. A backend running manual VACUUM gets away with it because the portal snapshot carries the SPI read, but the autovacuum worker has neither a portal nor an active snapshot, so the catalog query behind the summary fails:

WARNING:  cannot execute SQL without an outer snapshot or portal
CONTEXT:  SQL statement "select sum(file_size)::bigint from lake_table.files where table_name OPERATOR(pg_catalog.=) $1"

The error only gets caught at the top of the worker loop, so any autovacuum cycle that compacts something loses the summary and duration log lines and skips the remaining vacuum stages and tables for that cycle.

This PR pushes a snapshot around the catalog read so the summary works on both paths. Since the summary line previously reported only the remaining size in bytes, the same catalog query now also returns the number of files and live rows left in the table, completing the totals requested in #40:

LOG:  pg_lake: compacted iceberg table public.t: rewrote 3 files (849 bytes, 3 rows) into 1 files (303 bytes, 3 rows); table is now 303 bytes across 1 files (3 rows)

Tests: extended the existing summary test with the new totals, and added an autovacuum path test that reads the server log and verifies the summary appears from the worker without the snapshot error.

closes: #40