[chore] migração de dbt-core para dbt Fusion

## Contexto

A dbt Labs lançou o **dbt Fusion engine (v2.0)**, uma nova engine escrita em Rust que substitui o `dbt-core`. Como o projeto atual roda com `dbt-core==1.8` e `dbt-bigquery==1.8` (ver `pyproject.toml`), é necessário planejar a migração antecipando pontos de atenção, conflitos e impactos no deploy.

Estado atual do projeto:
- `dbt-core==1.8` / `dbt-bigquery==1.8` (em `pyproject.toml`)
- `dbt_utils` 1.1.1 (em `packages.yml`)
- Execução via `uv run dbt ...` dentro da imagem Docker (`Dockerfile`)
- Macros customizadas em `macros/`, incluindo `set_datalake_project`
- Testes customizados em `tests-dbt/` (ex.: `custom_unique_combinations_of_columns`, `not_null_proportion_multiple_columns`)

## Objetivo

Migrar o projeto `pipelines` do `dbt-core` para o **dbt Fusion**, garantindo paridade funcional dos modelos, testes e do pipeline de deploy.

---

## 1. Pontos de atenção na documentação do dbt Fusion

Investigar e validar no projeto:

- [ ] **Manifest v20 (incompatível com Core v12)**: Fusion não interopera com manifests antigos. Antes de usar `state:modified` ou `--defer`, todos os ambientes precisam estar em Fusion.
- [ ] **Resolver todos os deprecation warnings** existentes (a partir do dbt Core 1.10 são bloqueantes). Rodar `dbt-autofix` como passo preparatório.
- [ ] **Flags de CLI removidas/alteradas**:
- `--models` / `-m` → `--select` / `-s` (auditar scripts, agents e CI)
- `--resource-type` → `--resource-types`
- `--partial-parse` / `--no-partial-parse` removidos
- [ ] **Validação em parse-time mais estrita**: macros inexistentes, generic tests inexistentes, variáveis indefinidas e docs blocks duplicados passam a quebrar o parse.
- [ ] **YAML anchors standalone** precisam migrar para a chave `anchors:` (auditar `schema.yml` de cada dataset).
- [ ] **`config.get()` para chaves de `meta`** deve virar `config.meta_get()` / `config.meta_require()`.
- [ ] **Comportamento do `dbt clean`** muda: não apaga arquivos em resource paths configurados.
- [ ] **Unit tests** passam a rodar primeiro em `dbt build`.
- [ ] **Suporte ao adapter BigQuery está em Preview** no Fusion — validar autenticação via service account (modelo atual do projeto) e checar funcionalidades específicas usadas (partitioning, `set_datalake_project`, `st_geogfromtext`).
- [ ] **Compatibilidade do `dbt_utils`**: verificar se a versão pinada (1.1.1) é Fusion-compatible ou se exige bump (`require-dbt-version` precisa incluir `2.0.0`). O mesmo para qualquer pacote terceiro.
- [ ] **Macros e testes customizados** (`macros/`, `tests-dbt/`): revisar quanto à validação mais estrita e ao novo comportamento de `adapter.get_relation`.

## 2. Possíveis pontos de conflito na migração

- [ ] Auditar todos os `schema.yml` que usam `>` block scalar e anchors — Fusion exige nova sintaxe.
- [ ] Auditar uso de `--models` em workflows (Prefect flows, GitHub Actions, agents Claude — ver `.claude/rules/dbt-conventions.md`).
- [ ] Avaliar impacto nas convenções atuais documentadas em `.claude/rules/dbt-conventions.md` (atualizar para refletir Fusion).
- [ ] Confirmar suporte completo a particionamento BigQuery por `INT64` (`ano`) e `DATE` (`data`) usado nas convenções do projeto.
- [ ] Reavaliar `dbt deps` no build da imagem (etapa atual do `Dockerfile` linha 60) — Fusion altera o fluxo de instalação de pacotes.
- [ ] Verificar comportamento de `persist_docs` e `post-hook` (GRANT em `dbt_project.yml`) no Fusion.

## 3. Implicações de deploy e setup nos Docker images

Setup atual (ver `Dockerfile`):
- Base: `ghcr.io/astral-sh/uv:python3.10-bookworm-slim`
- Instalação via `uv sync --locked --no-dev` a partir de `pyproject.toml`
- `dbt` executado via venv: `uv run dbt deps`

Investigar:

- [ ] **dbt Fusion é um binário Rust standalone**, não um pacote Python — `pip/uv install dbt-core` deixa de ser o método de instalação. Necessário baixar o binário (script oficial de install ou release no GitHub `dbt-labs/dbt-fusion`).
- [ ] Atualizar o `Dockerfile` para:
- Remover `dbt-core` / `dbt-bigquery` do `pyproject.toml` (ou manter um trilho híbrido durante a transição)
- Baixar o binário `dbt` Fusion na etapa de build (curl + checksum + colocar em `/usr/local/bin`)
- Validar que `uv run dbt deps` continua funcionando ou substituir pelo comando equivalente do Fusion
- [ ] Verificar se as imagens utilizadas pelos flows do Prefect (chamadas em `pipelines/`) precisam ser republicadas com a nova imagem.
- [ ] Avaliar tamanho da imagem final e tempo de build (binário Rust pode reduzir cold-start).
- [ ] Reavaliar `profiles.yml` quanto a campos novos/depreciados do Fusion BigQuery adapter.
- [ ] Garantir paridade entre execução local (desenvolvedores) e CI/CD — documentar em `AGENTS.md` e `.claude/rules/dbt-conventions.md`.

## Critérios de aceite

- [ ] `dbt-autofix` executado e diffs aplicados.
- [ ] Todos os `schema.yml` passam no parse do Fusion sem warnings.
- [ ] `dbt build` completo executa com sucesso em dev (`basedosdados-dev`) com paridade de outputs vs. baseline atual.
- [ ] Imagem Docker atualizada, publicada e testada em pelo menos um flow Prefect.
- [ ] Documentação atualizada (`AGENTS.md`, `.claude/rules/dbt-conventions.md`, `.claude/rules/onboarding-workflow.md`).

## Referências

- [Upgrading to the dbt Fusion engine (v2.0)](https://docs.getdbt.com/docs/dbt-versions/core-upgrade/upgrading-to-fusion)
- [Upgrade to Fusion part 2: Making the move](https://docs.getdbt.com/guides/upgrade-to-fusion)
- [Quickstart for the dbt Fusion engine](https://docs.getdbt.com/guides/fusion)
- [dbt-labs/dbt-fusion (GitHub)](https://github.com/dbt-labs/dbt-fusion)
- [dbt-autofix](https://github.com/dbt-labs/dbt-autofix)