Consolida evolução do FluentMap até etapa 6

[rodri-oliveira-dev]

Resumo

Este PR consolida a evolução do Dapper.FluentMap acumulada nas etapas 1 a 6, usando os relatórios em docs/sdd/etapa-* como referência para descrever o escopo.

Ajustes principais

• Corrige a resolução de expressões de mapping para usar o membro real da expression tree, incluindo conversões legítimas de Expression<Func<TEntity, object>>.
• Consolida a composição de precedência entre mapping explícito, mapping herdado, conventions/naming policies e fallback do Dapper.
• Introduz MappingRegistry, chaves de cache estruturadas, invalidação por tipo e testes de integração reais com Dapper.
• Adiciona MemberPath, validação fail-fast com FluentMapConfigurationException, IncludeBase<TBase>() e naming policies (SnakeCase, prefix/suffix/custom e composição).
• Moderniza o registro com AddMap<TMap>(), discovery por assembly, constructor mapping para tipos imutáveis/records simples, Validate() e Explain<TEntity>().
• Adiciona pacotes de tooling Dapper.FluentMap.Analyzers e Dapper.FluentMap.Generators, incluindo AddGeneratedMappings().
• Documenta e anota APIs sensíveis a trimming/AOT, preservando netstandard2.0 no core.
• Adiciona materialização opt-in via QueryMapped* para nested objects, Value Objects imutáveis e mapping profiles query-scoped.
• Formaliza o lifecycle de configuração, adiciona snapshots read-only (GetEntityMaps() / GetTypeConventions()) e isola compatibilidade Dapper-specific em adapters internos.
• Atualiza o README público em inglês e PT-BR, diferenciando claramente Dapper.Query<T>() de QueryMapped*.
• Remove docs/, .agents/ e .tmp/ do versionamento e adiciona essas pastas ao .gitignore.

Impacto para consumidores

• APIs existentes foram preservadas sempre que possível.
• Novas capacidades avançadas são opt-in, principalmente QueryMapped* e mapping profiles.
• Dapper.Query<T>() continua sendo o caminho padrão para mappings simples e fallback do Dapper.
• Assembly scanning permanece suportado, mas é documentado como sensível a trimming; registro explícito ou gerado é o caminho recomendado para publicação trimmed/AOT.

Validação

Executado localmente:

dotnet restore ./Dapper.FluentMap.sln
dotnet build ./Dapper.FluentMap.sln --configuration Release --no-restore
dotnet test ./Dapper.FluentMap.sln --configuration Release --no-build
dotnet pack ./Dapper.FluentMap.sln --configuration Release --no-build --output ./artifacts/packages

Resultado observado:

• Build Release passou com 0 warnings e 0 erros.
• Testes passaram: 231 aprovados.
• Pack passou; apenas warnings NuGet já conhecidos sobre licenseUrl / ausência de package README no core e Dommel.

Observações

• A documentação interna consultada permanece local, mas deixou de ser versionada por solicitação explícita.
• O spike da etapa 6 conclui que materializer gerado é viável com restrições, mas o runtime de produção ainda mantém fallback reflection-based.
• Compatibilidade Native AOT completa não é declarada; claims futuros exigem validação runtime em ambiente adequado.