bd.Table.create() só registra o ponteiro externo do BigQuery em basedosdados-staging, nunca em basedosdados-dev

## Resumo

`bd.Table.create()` (pacote `basedosdados`, usado por `upload_to_gcs`/pelo fluxo de materialização) registra a tabela externa do BigQuery — o "ponteiro" que permite fazer `SELECT` sobre os arquivos no GCS — sempre dentro de um projeto fixo, `gcloud-projects.staging.name` (`~/.basedosdados/config.toml`), que no ambiente real é `basedosdados-staging`. Não existe parâmetro em `Table()`/`bucket_name`/`billing_project_id` que mude esse destino.

O problema: a macro dbt `set_datalake_project` (`macros/set_datalake_project.sql`) resolve o projeto consultado de forma diferente por target:

```
target=dev → basedosdados-dev
target=prod → basedosdados-staging
```

Ou seja, qualquer flow que rode `dbt run/test` com `target=dev` (como o `mat_test_flow` da #1867, que roda dev antes de prod) espera achar a tabela externa em `basedosdados-dev` — mas `bd.Table.create()` só a cria em `basedosdados-staging`. Sem uma segunda cópia manual do ponteiro em `basedosdados-dev` (mesmo schema, mesma config de particionamento Hive quando aplicável), o `dbt run --target dev` falha por tabela não encontrada.

## Por que abrir agora

Achado durante o teste de ponta a ponta da #1867 (pipeline orientado a eventos) com um piloto novo (`test_dataset.test_event_pipeline_partitioned`). Foi o mais difícil de diagnosticar entre os problemas encontrados nesse teste: o piloto original (`test_event_pipeline`) já dependia dessa segunda cópia manual — criada em algum momento anterior da sessão, sem virar código nem documentação — então o gap ficou invisível até faltar de novo num piloto novo.

Qualquer dataset novo que siga esse fluxo (`upload_to_gcs` → `dbt run --target dev`) bate na mesma parede, sem aviso — o erro só aparece como "tabela não encontrada" em tempo de execução do dbt, sem apontar pra causa real.

## Proposta

Duas alternativas, a decidir por quem tem mais contexto de por que a separação staging/dev existe:

1. `upload_to_gcs`/`Table.create()` (ou um wrapper em `pipelines/utils/`) passa a criar as duas cópias do ponteiro externo automaticamente (`basedosdados-staging` e `basedosdados-dev`), sempre que aplicável — inclusive replicando `HivePartitioningOptions` quando o dado é particionado.
2. Ou o pipeline deveria depender de só uma das duas cópias — revisitar por que a macro dbt resolve `target=dev` pra um projeto diferente de onde o dado é de fato registrado, e alinhar os dois.

Não decidido aqui qual caminho é o certo — abrindo pra registrar o gap e discutir.

## Achado durante

basedosdados/pipelines#1867 (pipeline orientado a eventos), piloto `test_event_pipeline_partitioned`. PR #1932.