build: compile the duckvfs backend into the image

[jrosskopf]

The published image was built --features gemini,s3,gcs, so the duckvfs LaneStore was not in the binary at all. Setting ESCUREL_STORAGE_BACKEND=duckvfs against it fails at boot:

ESCUREL_STORAGE_BACKEND=duckvfs requires the 'duckvfs' cargo feature; this binary was built without it

So the image could not serve a Google Drive lane store, which is the backend's whole reason for existing.

Cost: none

The feature is dep:duckdb, and libduckdb is already linked for escurel-index. No new native dependency, no new system package. The backend was absent for no benefit.

Verified by running the image, not by reading the Dockerfile

• cargo check -p escurel-server --features gemini,s3,gcs,duckvfs passes — no feature-interaction problem
• The container boots with ESCUREL_STORAGE_BACKEND=duckvfs and reports healthy, where the old image exits on the feature error
• The duckdb-gdrive extension is actually fetched inside the container: /tmp/e/.duckdb/extensions/v1.5.5/linux_amd64/gdrive.duckdb_extension, 20 MB, pulled from the community repository on first use

That last check is the one worth keeping. The feature being compiled in only means the backend exists; it still needs egress and a writable $HOME for ~/.duckdb at runtime, and neither is visible from the Dockerfile. A pod whose $HOME is not writable would boot, report healthy, and fail on first use — so the Dockerfile now records both requirements next to the feature list.

Deployment note

Needs ESCUREL_STORAGE_DUCKVFS_EXTENSION_REPO=community (#433). Without it — and without an explicit ..._EXTENSION path — the load is skipped rather than failing, so the store opens cleanly and the first write fails on a missing write_blob.

Dockerfile is in publish-image.yml's paths: filter, so merging republishes :main and a new :<sha>.

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}