fix(experimental): point GDAL at the Debian CA bundle

The raster extension vendors a GDAL whose libcurl is built with the RedHat CA
path (/etc/pki/tls/certs/ca-bundle.crt), which does not exist on the python:slim
Debian base. Every /vsicurl/ read failed with 'CURL error: error setting
certificate file' while RT_* functions themselves loaded fine, so the extension
looked healthy right up until it touched the network.

Author: cboettig

Dockerfile.experimental

@@ -23,6 +23,14 @@ COPY . /app
 # default image, which therefore behaves exactly as before.
 ENV EXTRA_DUCKDB_EXTENSIONS=raster,zarr
 
+# The raster extension ships its own GDAL, whose libcurl is compiled with the
+# RedHat CA path (/etc/pki/tls/certs/ca-bundle.crt). The base image is Debian, so
+# every /vsicurl/ read fails with "CURL error: error setting certificate file"
+# until GDAL is pointed at the Debian bundle. Both names are set because which one
+# a given GDAL build honours depends on how it was compiled.
+ENV GDAL_HTTP_CAINFO=/etc/ssl/certs/ca-certificates.crt \
+    CURL_CA_BUNDLE=/etc/ssl/certs/ca-certificates.crt
+
 ARG APP_VERSION=experimental
 ARG GIT_SHA=unknown
 ENV APP_VERSION=$APP_VERSION GIT_SHA=$GIT_SHA

k8s/experimental-deployment.yaml

@@ -40,6 +40,13 @@ spec:
         # extras a running pod believes it has without cracking open the image.
         - name: EXTRA_DUCKDB_EXTENSIONS
           value: "raster,zarr"
+        # GDAL (vendored by the raster extension) looks for the RedHat CA path;
+        # the image is Debian. Without this every /vsicurl/ read fails TLS. Also
+        # set in the image — repeated here so it is visible and overridable.
+        - name: GDAL_HTTP_CAINFO
+          value: "/etc/ssl/certs/ca-certificates.crt"
+        - name: CURL_CA_BUNDLE
+          value: "/etc/ssl/certs/ca-certificates.crt"
         - name: POD_MEMORY_LIMIT
           valueFrom:
             resourceFieldRef: