Passo 3 v2.0.0: mapeamento de perfis de carga confirmado contra export real

- docs/13-v2-perfis-carga.html: mapeamento completo coluna a coluna pra
  DL_TECH_CMDB_V2 (12 campos) e DL_TECH_VULNERABILIDADE_V3 (23 campos),
  conferido campo a campo contra um export real (Artefatos/ da
  V1_Cliente, só linhas AM...) em vez de suposição.
- Correções encontradas na conferência: definition.patch_published e
  definition.vulnerability_published têm prefixo 'definition.' no
  export real (não estava assim documentado antes); flags booleanos
  confirmados como texto 'true'/'false' (Tenable) e
  'Verdadeiro(a)'/'Falso(a)' (ServiceNow, mesma convenção já usada em
  SOX/COFRE/TENABLE/SIEM no capítulo 10).
- RAW_JSON deliberadamente fora do escopo deste passo — Data Load só
  carrega colunas mapeadas, não a linha completa; população real de
  RAW_JSON depende da tabela de staging (próximo item do TASKS.md).
- Nav (13 páginas) e pillnav do capítulo 12 atualizados.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

TASKS.md

@@ -43,7 +43,10 @@ teste — a menos que você peça explicitamente o contrário.
       (bloco grande) foi pulado na primeira passada — o checkpoint de compilação deu `VALID`
       porque a view *antiga* (46 colunas) já era válida antes. Resolvido rodando o bloco
       explicitamente; segunda checagem confirmou as 81 colunas.
-- [ ] Novos perfis de carga (`DL_TECH_VULNERABILIDADE_V3`, `DL_TECH_CMDB_V2`)
+- [ ] **Mapeamento pronto e confirmado contra export real** (ver
+      [docs/13-v2-perfis-carga.html](docs/13-v2-perfis-carga.html)) — falta só criar os dois
+      perfis de fato no App Builder (não é scriptável, precisa ser feito na UI). `RAW_JSON`
+      deliberadamente fora do escopo deste item — depende do item de staging abaixo.
 - [ ] Pipeline de staging: bucket → `TB_26AI_TECH_V2_STG` via `DBMS_CLOUD.COPY_DATA` (tabela nova,
       não mexe nas existentes)
 - [ ] `MERGE` com histórico (`LOAD_BATCH_ID`, `TB_26AI_TECH_V2_HIST` — tabela nova), honrando o