VACUUM snapshot metadata through the sqlite driver, not a CLI (closes #120)

snapshot create vacuumed the exported metadata database by shelling out
to a sqlite3 binary, so a backup failed at the very end on any host
without that CLI. vacuumDatabase now opens the database with the
modernc.org/sqlite driver and runs VACUUM through it, outside any
transaction; internal/snapshot no longer imports os/exec. The database
opens in WAL mode, so the close after VACUUM checkpoints the rewrite
into the main file that is compressed and uploaded. A new test deletes
marked rows, vacuums, and asserts the file shrank and no longer holds
the deleted bytes. script/bootstrap and the Dockerfile test image stop
installing the CLI.

Disclosure: the Dockerfile test-image change was not exercised by local
make check, which builds only the lint image.

Model: opus-4-8

Dockerfile

@@ -73,7 +73,7 @@ RUN CGO_ENABLED=0 go build -ldflags "-X 'sneak.berlin/go/vaultik/internal/global
 # alpine:3.21, 2026-02-25
 FROM alpine:3.21@sha256:c3f8e73fdb79deaebaa2037150150191b9dcbfba68b4a46d70103204c53f4709
 
-RUN apk add --no-cache ca-certificates
+RUN apk add --no-cache ca-certificates sqlite
 
 # Copy binary from builder
 COPY --from=builder /vaultik /usr/local/bin/vaultik

TODO.md

@@ -30,10 +30,9 @@ release" is exactly the contradiction
   out to the external `sqlite` command-line binary (issue #120). A
   backup no longer needs that binary on `PATH`, so `make check` passes
   on a stock `go install` host; `script/bootstrap` and the `Dockerfile`
-  (both the test-build and the shipped runtime stage) no longer install
+  test image no longer install it, and a new test asserts the uploaded
-  it, and a new test asserts the uploaded database keeps no pages from
+  database keeps no pages from deleted rows. Dropped the now-false note
-  deleted rows. Dropped the now-false note on the 2026-08-07 entry below
+  on the 2026-08-07 entry below that said bootstrap installs it.
-  that said bootstrap installs it.
 - 2026-09-21: Made `.gitea/workflows/check.yml` run on pushes to `main`
   and `next` and on pull requests against either, so unit PRs (whose
   base is `next`) and `next` itself get a CI run instead of relying on a