Passo 2 v2.0.0: V_26AI_TECH + prc_26ai_tech expõem campos novos ao LLM

- sql/04_v2_view_procedure_update.sql: CREATE OR REPLACE VIEW V_26AI_TECH
  (+35 colunas: 23 de TB_26AI_TECH_V2 + 12 de TB_26AI_TECH_CMDB, RAW_JSON de
  cada tabela virou RAW_JSON_TENABLE/RAW_JSON_CMDB pra não colidir nome) e
  CREATE OR REPLACE PROCEDURE prc_26ai_tech (só o json_object do ramo VUL
  ganhou os campos novos; ramo SYS, prompt, vetorização, log e exceção
  ficam byte-a-byte idênticos ao script original).
- Depende do Passo 1 (03_v2_ddl_schema_evolution.sql) já ter rodado no
  mesmo ambiente.
- TASKS.md atualizado.

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

TASKS.md

@@ -33,7 +33,11 @@ teste — a menos que você peça explicitamente o contrário.
       incluindo `RAW_JSON` CLOB catch-all em cada uma), 100% aditivo (sem DROP), com checkpoint de
       validação embutido no próprio script. **Pendência antes de rodar:** decidir em qual ambiente
       (o atual está marcado como intocável — ver seção "Ponto de partida" acima).
-- [ ] Atualizar `V_26AI_TECH` + `json_object` de `PRC_26AI_TECH` para expor os campos novos ao LLM
+- [ ] **Pronto, aguardando você rodar e validar** — `sql/04_v2_view_procedure_update.sql`:
+      `V_26AI_TECH` ganha as 35 colunas novas (aliases `RAW_JSON_TENABLE`/`RAW_JSON_CMDB` pra não
+      colidir); `prc_26ai_tech` passa a incluir esses campos no `json_object` enviado ao LLM (só o
+      ramo `VUL` foi tocado — ramo `SYS`, prompt, vetorização, log e exceção ficam idênticos ao
+      original). **Depende do Passo 1 já ter rodado no mesmo ambiente.**
 - [ ] Novos perfis de carga (`DL_TECH_VULNERABILIDADE_V3`, `DL_TECH_CMDB_V2`)
 - [ ] Pipeline de staging: bucket → `TB_26AI_TECH_V2_STG` via `DBMS_CLOUD.COPY_DATA` (tabela nova,
       não mexe nas existentes)