feat(duckvfs): install the extension from the community repository

[jrosskopf]

The duckvfs lane store could not be deployed to a container. This makes it deployable.

The problem

extension_path names a locally built gdrive.duckdb_extension. It is the only way to register write_blob / remove_file / file_size, which live in the extension rather than DuckDB core and are needed for every root, not only gdrive://. A pod has no such file.

Leaving it unset is the worse failure, not an escape: None skips the load and assumes the functions are present. The store then opens cleanly and the first write fails with Catalog Error: Scalar Function with name write_blob does not exist!. A boot that succeeds and a write path that cannot work is the shape that reaches production looking healthy.

The change

gdrive now ships in the DuckDB community repository — which duckvfs.rs already anticipated in a comment ("Once gdrive is in the community repository this becomes INSTALL gdrive FROM community; LOAD gdrive;"). extension_repo is that, as ESCUREL_STORAGE_DUCKVFS_EXTENSION_REPO: community, or a repository URL.

A new field, not a redefinition of extension_path: None. Repurposing None would change behaviour for existing file:// roots and force a network install where none happens today. extension_path keeps its exact meaning and still takes precedence, so an operator pointing at a local build always gets that build.

One detail encoded in the code: community is a keyword in DuckDB's grammar and must not be quoted, while a URL must be. Quoting the keyword makes DuckDB look for a repository literally named "community" and fail with a message that says nothing about quoting.

Verification

Red → green, plus two checks — the second is the one that mattered.

1. Load-bearing: mutating extension_repo to None fails the test with the missing-write_blob error. It asserts a write round trip, not that the constructor returns Ok — new performs no I/O against the root, so a store that never loaded the extension constructs perfectly.
2. Not just my cache: it first passed in 0.65s, too fast for a download — gdrive.duckdb_extension was already in ~/.duckdb/extensions/v1.5.5/linux_amd64/ from local use. Re-run with a cold HOME it genuinely downloads, populates the fresh cache and passes. That is the container case; the deployment already sets HOME to a writable dir. Without this check the test would have been green here and broken everywhere it is actually needed.

The new test deliberately takes no ESCUREL_TEST_GDRIVE_EXTENSION — needing a prebuilt file is the thing being removed. It does need network access to the community repository.

1377 passed, 0 failed, clippy clean. API contract unchanged.

Why now

This unblocks running an Escurel in the cluster against the existing gdrive-backed lake (the datazoo-loops corpus) rather than moving that data. The remaining pieces are a WIF credential for the Drive, a catalog DSN secret, and the substrate app.

---

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