feat(lakehouse): support Azure Blob storage for DuckLake

[JakeHarveyy]

What

Adds Azure Blob Storage as a storage: backend for the DuckDB DuckLake lakehouse connection, alongside the existing s3 and gcs backends.

duckdb:
  - name: my_ducklake
    lakehouse:
      format: ducklake
      catalog:
        type: postgres
        # ...
      storage:
        type: azure
        path: "az://my-container/path"
        auth:
          connection_string: "${AZURE_STORAGE_CONNECTION_STRING}"

Two auth modes:

• connection_string — account-key auth.
• account_name only — uses DuckDB's credential_chain provider (managed identity / az login / environment credentials).

Why

DuckLake stores its Parquet on object storage, and DuckDB fully supports Azure Blob via the azure extension — but Bruin's lakehouse connection only accepts s3/gcs, so DuckLake pipelines can't target Azure. This closes that gap for Azure deployments. Follows the same shape as the GCS (#1758) and S3-compatible (#1994/#1999) backends.

How

• pkg/config/lakehouse.go: StorageTypeAzure + supportedStorageTypes; StorageAuth.ConnectionString/AccountName (+ IsAzure()).
• pkg/duckdb/lakehouse.go: DuckLake validation for azure, loads the azure extension, generateAzureSecret() (CREATE SECRET (TYPE azure, …)), and the attach flow.
• generateDuckLakeAttach is unchanged — az://… flows through as DATA_PATH and the secret's SCOPE authorizes it.

Generated SQL for type: azure:

INSTALL azure; LOAD azure;
SET GLOBAL azure_transport_option_type = 'curl';
CREATE OR REPLACE SECRET bruin_<alias>_storage (TYPE azure, CONNECTION_STRING '…', SCOPE 'az://…');
-- + catalog secret + ATTACH 'ducklake:postgres:' (DATA_PATH 'az://…', …)

Note on the curl transport

azure_transport_option_type = 'curl' is set globally for azure storage. The azure extension's default transport ignores the system CA bundle and fails TLS to *.blob.core.windows.net on Linux/containers; curl uses libcurl + the standard CA paths (host needs ca-certificates). It's GLOBAL rather than session-scoped because DuckLake maintenance calls otherwise still fail — see duckdb/ducklake#776. Happy to make this configurable (or opt-in) if you'd prefer.

Scope

DuckLake only. Iceberg-on-Azure remains unsupported (untested).

Tests

pkg/duckdb/lakehouse_test.go: config validation (pass / missing-auth / missing-path), required extensions, generateAzureSecret golden strings (connection_string + credential_chain), and the full attach-statement sequence.

Docs

• docs/platforms/duckdb.md: #### Azure config examples, auth modes, transport/CA note, maintenance-func caveat.
• docs/getting-started/lakehouse.md: Azure column in the DuckLake support table.

[greptile-apps]

PR author is not in the allowed authors list.

[JakeHarveyy]

Verified the unit tests pass locally (CI here is awaiting first-time-contributor approval):

go test -tags="no_duckdb_arrow" ./pkg/config/ ./pkg/duckdb/
ok  github.com/bruin-data/bruin/pkg/config   0.013s
ok  github.com/bruin-data/bruin/pkg/duckdb   0.025s

New azure coverage all green: TestLakehouseAttacher_GenerateAzureSecret (connection_string + credential_chain + empty), GetRequiredExtensions (azure ext), GenerateAttachStatements (asserts INSTALL/LOAD azure, SET GLOBAL azure_transport_option_type='curl', CREATE SECRET TYPE azure, ATTACH … DATA_PATH 'az://…'), and TestValidateLakehouseConfig azure pass/missing-auth/missing-path cases.

These are unit tests over the generated SQL; I haven't run an E2E against a live Azure storage account.