story: expor detect_layout no MCP após estabilizar o contrato

[elson-vinicius-lopes]

Story pai

#213

Dependência no consumidor

LayoutParser/LayoutParserReact#184.

Objetivo

Após estabilizar o endpoint e o schema de #213, expor uma tool MCP tipada detect_layout no LayoutParserMcp, mantendo o servidor como cliente fino da API.

Critérios de aceite

• A tool representa unique, ambiguous e not_found sem reinterpretar regra de domínio.
• X-Correlation-ID é criado/propagado e permite correlação com a API.
• stdout permanece exclusivo do protocolo MCP; logs seguem em stderr/arquivo.
• Nenhum documento, layout descriptografado, identidade ou segredo aparece em logs.
• Limites e erros HTTP do endpoint são preservados de modo seguro.
• api_post continua disponível como fallback de descoberta, sem duplicar o matcher.
• README e exemplo de configuração são atualizados somente após o contrato final.

Bloqueio

Não iniciar antes da aprovação do contrato de #213 e do gate estrutural mínimo.

Critérios adicionais — Top 5 e override

• schema tipado representa até cinco candidatos, total, truncamento, rank, score/componentes, evidências, conflitos, limitações e empates;
• diferencia candidato compatível de sugestão aproximada;
• não cria seleção implícita para ambiguous ou not_found;
• escolha explícita e override propagam o snapshot/versionamento requerido pela API;
• retorno inclui origem da escolha, rank/score apresentado, versões, correlationId e identificador de auditoria;
• erros de adulteração, expiração ou mudança de catálogo são preservados de forma segura, sem retry que selecione outro layout automaticamente.

[elson-vinicius-lopes]

O contrato HTTP necessário está no PR #222. A tool MCP tipada detect_layout permanece intencionalmente pendente nesta issue; após a promoção, o MCP genérico poderá exercitar o endpoint via api_post sem duplicar regra de domínio.