feat: cache da data exploration por pergunta

[Petroncini]

Resumo

A cada falha de execução o retriever amplia o top_k (8 → 12 → 16 tabelas) e o nó de data exploration recalculava as estatísticas de todas as tabelas, inclusive as já exploradas na tentativa anterior. Foi uma das causas da latência subir de 13s para 31s por pergunta no BIRD.

Agora o estado guarda cache_data_exploration (contagem de linhas + linha formatada de cada coluna já explorada) e cada execução só calcula o que é novo. O texto enviado ao prompt é o mesmo de antes.

• Cache zerado por pergunta em construir_estado_inicial (o LangGraph mescla o input novo no estado salvo da mesma thread_id).
• Granularidade por coluna, porque o exploration selector pode pedir colunas diferentes a cada passada.
• Funciona com db_path e com db_engine.

Medição

Banco Baseball do Spider 2 (26 tabelas), simulando as 3 tentativas com 8/12/16 tabelas:

	1ª	2ª	3ª	total
sem cache	0.93s	0.96s	1.20s	3.09s
com cache	0.94s	0.04s	0.25s	1.23s (−60%)

Testes

• 8 testes novos em tests/test_data_exploration.py: texto idêntico ao formatador sem cache, repetição sem reexplorar, expansão só das tabelas novas, só colunas faltantes, ordem original após exploração completa, cache serializável e não mutado, reset no estado inicial.
• 7 desses falham com o nó antigo (conferido).
• Suíte completa: 163 passed, 1 skipped.