fix: timeout do provedor nunca chegava ao httpx; endpoint agora visível

Causa do 'Provedor de LLM indisponível' no ambiente com Ollama local foi
externa: OLLAMA_BASE_URL exportada no shell (http://localhost:11434/v1) vence o
.env na interpolação do docker-compose, e localhost dentro do container é o
próprio container. Nada no app indicava a URL em uso.

Dois defeitos de código que tornavam isso indetectável — e um deles produziria a
mesma mensagem mesmo com a URL correta:

- _BaseProvider criava o httpx.AsyncClient com o atributo de classe (120 s) e as
  subclasses atribuíam self.timeout depois. O httpx congela o timeout na
  construção, então os 300 s pedidos pelo Ollama nunca valeram: um primeiro
  atendimento com modelo frio era cortado em 120 s com exatamente a mensagem
  'provedor indisponível'. O timeout agora é passado ao super().
- LLMProviderError de conexão não citava o endereço tentado; o log dizia só 'All
  connection attempts failed'. Passa a incluir a endpoint, com credenciais
  user:pass@ redigidas. /api/health expõe llm_endpoint para comparação direta
  com o .env.

README e .env.example documentam a precedência shell > .env, o fato de /v1 ser a
superfície OpenAI-compatível (o adaptador usa /api/chat nativo) e a latência
medida do primeiro atendimento.

README.md

@@ -206,6 +206,32 @@ aceita `POST`.
 
 Todas as variáveis ficam no `.env`. As principais:
 
+> ### Cuidado: variável do shell vence o `.env`
+>
+> O docker-compose resolve `${VAR:-padrão}` olhando **primeiro o ambiente do
+> shell**, e só depois o arquivo `.env`. Uma variável exportada na sua sessão —
+> por outra ferramenta, um `export` no perfil, um `direnv` — sobrescreve o `.env`
+> **sem nenhum aviso**.
+>
+> Foi exatamente assim que o chat quebrou com "Provedor de LLM indisponível": um
+> `OLLAMA_BASE_URL=http://localhost:11434/v1` herdado do shell fez o backend
+> tentar conectar em `localhost` **dentro do próprio container**, onde não há
+> nada na porta 11434. O `.env` dizia `http://ollama:11434` e continuou dizendo,
+> sem efeito.
+>
+> Confira o valor que será realmente aplicado:
+>
+> ```bash
+> docker compose --profile local config | grep -A2 'ollama:'   # ou:
+> docker compose --profile local config | grep OLLAMA_BASE_URL
+> curl -s localhost:8030/api/health | grep llm_endpoint        # o que está em uso
+> ```
+>
+> Para o valor do `.env` valer, rode limpo: `env -u OLLAMA_BASE_URL docker compose --profile local up -d`.
+>
+> Nota: `/v1` é a superfície compatível com OpenAI. O adaptador Ollama usa a API
+> nativa (`/api/chat`), então a URL **não** deve terminar em `/v1`.
+
 | Variável | Padrão | Efeito |
 |---|---|---|
 | `LLM_PROVIDER` | `ollama` | `ollama`, `openai`, `groq`, `anthropic` ou `stub` |
@@ -230,6 +256,30 @@ Nenhum dos dois lados da busca encontrou nada acima do piso. Confira `/api/statu
 pergunta citar uma referência explícita (`João 3:16`), a busca é determinística por
 metadados e não depende de limiar nenhum.
 
+**"Provedor de LLM indisponível" no chat.**
+Três causas possíveis, nesta ordem de probabilidade:
+
+1. **A URL não é a que você acha.** Veja `curl -s localhost:8030/api/health | grep llm_endpoint`
+   e compare com o `.env`. Variável exportada no shell sobrescreve o `.env` em
+   silêncio (ver aviso na seção Configuração). `localhost` dentro do container é o
+   próprio container — para falar com o Ollama do Compose o nome é `ollama`.
+2. **O serviço não está no ar.** Com `LLM_PROVIDER=ollama`, o Ollama só sobe com o
+   profile: `docker compose --profile local up -d`. Confira com
+   `docker compose exec -T backend curl -s http://ollama:11434/api/tags`.
+3. **O modelo não está no volume.** `ollama run` no host não alimenta o container;
+   o volume é `ollama:/root/.ollama`. Liste os modelos de dentro do container:
+   `docker compose exec ollama ollama list`.
+
+O log do backend traz a endpoint tentada: `docker compose logs backend | grep -i provedor`.
+
+**A primeira resposta demora muito.**
+Espera mesmo. O modelo precisa ser carregado na RAM e o prompt tem ~1.800 tokens
+(system + 6 trechos com janela de contexto), tudo em CPU. Medido com `llama3.2:1b`:
+~70 s com o modelo quente, bem mais no primeiro atendimento após o arranque. Como a
+validação de citação exige o texto completo antes de exibir, não há saída
+parcial. Modelos menores respondem mais rápido; `TOP_K` menor também reduz o
+prompt.
+
 **As respostas citam versículos que parecem fora do tema.**
 Verifique em `/api/status` o campo `model`. Se aparecer
 `hash-determinístico (sem semântica)` em vez do nome do modelo configurado, o