Respeitar o scheme do endpoint na conexão DuckLake (s3_use_ssl)

[maia-andre]

Resolve #72

O que muda com esse PR

_nova_conexao (utils/ducklake.py) passa a definir s3_use_ssl a partir do scheme do endpoint configurado, em vez de deixar o default do DuckDB (SSL sempre ligado) valer para qualquer endpoint:

Endpoint configurado	Antes	Depois
https://… (produção)	SSL ligado (default)	SSL ligado (explícito) — sem mudança
http://… (MinIO local, on-prem)	quebra com SSL connection failed	funciona

Isso destrava o desenvolvimento local com MinIO (#35) e abre caminho para testes de integração na CI com um S3 real como service container (#68).

Antes (main atual, MinIO local em http://localhost:9000):

Depois (este PR, mesma máquina, mesmos dados — pipeline NCM):

O lake no MinIO (bucket colibri-prod populado pelo colibri pipeline run ncm; a segunda imagem mostra exatamente o parquet que a URL do erro tentava alcançar):

Como testar

1. Subir um MinIO local: docker run --rm -p 127.0.0.1:9000:9000 -p 127.0.0.1:9001:9001 -e MINIO_ROOT_USER=... -e MINIO_ROOT_PASSWORD=... minio/minio server /data --console-address ":9001", criar o bucket colibri-prod.
2. Apontar o .segredos.yml para endpoint: http://localhost:9000 com as credenciais do passo 1.
3. Popular o lake: colibri pipeline run ncm.
4. Rodar colibri lake query "SELECT COUNT(*) FROM lake.main_intermediate.int_ncm" — sem este PR, falha com SSL connection failed; com ele, retorna as linhas.
5. Contra um endpoint https (produção), nada muda: s3_use_ssl = true é exatamente o default que já valia.

Checklist antes de mesclar na main

• Formatar todos os arquivos python usando ruff format .
• N/A yamlfix (nenhum yaml alterado)
• N/A pytest (repositório ainda não tem testes Python)
• N/A dbt test (nenhum modelo dbt alterado)

Obs.: ruff check utils/ducklake.py aponta 2 avisos pré-existentes (ordem de imports e except Exception no checkpoint), anteriores a este PR — deixados de fora para manter um assunto por PR.