[Databug] br_rf_cno.vinculos — linhas 100% duplicadas (~2,5%) sem teste de unicidade

### Tabela afetada
`br_rf_cno.vinculos`

### Descrição do problema nos dados
A tabela `br_rf_cno.vinculos` contém **linhas 100% duplicadas** (todas as colunas idênticas):
~**10.656** na partição mais recente (`data_extracao = 2026-07-17`), ~**2,5%** das 420.059 linhas
da partição. A duplicação vem da **própria fonte** (`cno_vinculos.csv` traz registros idênticos).

Passa despercebido porque a `vinculos` é a única tabela de dados do conjunto **sem** teste
`dbt_utils.unique_combination_of_columns` (a `areas` e a `microdados` têm). O modelo é
**incremental** (particionado por `data_extracao`), então cada snapshot vira uma partição e a
duplicação se acumula ao longo do histórico.

### Evidência
```sql
SELECT COUNT(*) AS linhas,
COUNT(*) - COUNT(DISTINCT TO_JSON_STRING(t)) AS linhas_duplicadas
FROM `basedosdados.br_rf_cno.vinculos` t
WHERE data_extracao = (SELECT MAX(data_extracao) FROM `basedosdados.br_rf_cno.vinculos`);
-- linhas = 420059 | linhas_duplicadas = 10656
```
Chave natural verificada (0 colisões após deduplicar):
`[id_cno, id_responsavel, data_inicio, data_fim, qualificacao_contribuinte]`.

### Encaminhamento sugerido
**Forward (PR de dbt):**
- `models/br_rf_cno/br_rf_cno__vinculos.sql`: `select distinct` no select final (espelha a `areas`).
- `schema.yml`: adicionar `unique_combination_of_columns` em
`[id_cno, id_responsavel, data_inicio, data_fim, qualificacao_contribuinte]`, escopado em
`__most_recent_date_cno__`.

**Histórico (limpar as partições já materializadas):**
- **Não usar `--full-refresh`**: o staging tem só **126 das 292 partições**, então full-refresh
reconstruiria do staging e **perderia ~166 partições**.
- Limpar in-place:
```sql
CREATE OR REPLACE TABLE `basedosdados.br_rf_cno.vinculos`
PARTITION BY data_extracao AS
SELECT DISTINCT * FROM `basedosdados.br_rf_cno.vinculos`
```
(dropa as Row Access Policies → reaplicar). É DML em dado público de prod → **requer aprovação**.

Obs.: o teste `unique_combination` só fica verde quando o partition máximo estiver limpo — via
partição nova pós-`distinct`, ou pela limpeza in-place acima.

### Referências
- #1658 — metadados do `br_rf_cno` (a duplicação foi encontrada nessa investigação)
- README da base: `pipelines/datasets/br_rf_cno/README.md` (seção `br_rf_cno__vinculos`)
- Guia: `manual-equipe-dados/docs/pipelines/como-fazer/abrir-issue.md`