Compress snapshot state.db to cut disk usage #147

Observed

First snapshot on a mature system landed at 198 MB (v0.31.0 on a site with 30 days of hot-tier telemetry + long-format TS). Five-slot retention ⇒ ~1 GB of snapshots on disk. Fine on a typical RPi install with a 32 GB card, less fine on smaller setups or when operators keep history longer.

Fix

Pipe `VACUUM INTO` output through gzip before writing. SQLite has a good compression ratio on the hot-tier tables (lots of repeated column headers, small numeric deltas) — expect 5-10×.

Two approaches:

1. Sidecar-free: run `VACUUM INTO` to a temp `.db`, then gzip it into the snapshot dir, remove temp. Two steps but no driver dependency.
2. SQLite VFS / in-memory compress: more invasive.

Preference: (1). Sufficient and self-contained.

Rollback reads the gzip transparently — update `restore` path (tracked in #140 phase 2) to `gunzip` before `docker compose stop` + file swap.

Scope

Follow-up to #141. Targeting Phase 2 rollback bundle so the compression + decompression paths ship together.