Resolver schema e coluna dinamicamente no colibri lake years

[maia-andre]

Resolve #80

O que muda com esse PR

• colibri lake years volta a funcionar: o schema é resolvido consultando o catálogo DuckLake (novo helper _resolver_tabela, extraído do lake download), em vez do lake.main fixo.
• Nova opção --coluna para o campo de ano/data; sem ela, a heurística tenta ano, depois ano_compra, senão falha listando as colunas candidatas.
• O agrupamento respeita o tipo da coluna: year() para DATE/TIMESTAMP e cast numérico para as demais — o que de quebra unifica os anos "2024"/"2024.0" (pncp_comprasgov: fixar tipo da coluna ano_compra #60) numa linha só enquanto o Converter ano_compra para inteiro no int_pncp_comprasgov__itens #75 não entra.
• lake download passa a usar o mesmo helper (menos duplicação), e nomes de tabela/coluna são validados contra o catálogo antes de entrar na query (elimina a interpolação cega por f-string).

Evidência

Antes (main) — qualquer tabela falha

Depois — heurística ano_compra (e os anos "2024"/"2024.0" unificados)

Depois — --coluna com coluna DATE

Como testar

colibri lake years int_pncp_comprasgov__compras          # heurística ano_compra
colibri lake years mrt_pncp_comprasgov_compras           # views funcionam
colibri lake years stg_margem__eventos --coluna data_evento
colibri lake years nao_existe                            # "Tabela não encontrada"
colibri lake download int_margem__ncm_prefixos           # regressão do download

Validado contra o lake de produção (somente leitura): totais idênticos aos do lake tables (902.636 / 880.695 / 3.117 / 2.543).

Checklist antes de mesclar na main

• Formatar todos os arquivos python usando ruff format .

(yamlfix, pytest e dbt test não se aplicam — nenhum YAML ou modelo dbt tocado; quando o PR #69 entrar, o smoke test passa a cobrir a CLI.)