Como corrigir estimativas de linha devido à junção de 2 resultados bem estimados

A consulta a seguir é executada em aproximadamente 60 bancos de dados em paralelo. Sem dicas, há inúmeros vazamentos e planos não ideais em pelo menos 10% dos BDs.

Usando um banco de dados maior como guia, a consulta foi bloqueada com dicas (~ 75ms em 1 CPU) para reduzir a variação nos tempos de execução, pois 1 plano ruim causa o tempo de execução geral. Nós nos opomos principalmente a permitir que cada banco de dados ajuste seu plano livremente, pois alguns bancos de dados provavelmente pegarão fogo a longo prazo na plataforma de produção. Estamos perfeitamente satisfeitos com um plano quase ideal para bancos de dados maiores que pode ser sub-ótimo para bancos de dados menores.

Alguns (~ 5) dos bancos de dados menores ainda exibem pequenos spills de Nível 1 (consulte o plano) mesmo após adicionar estatísticas com varredura completa. O tempo de execução ainda está ok (125ms), mas gostaria de eliminar o derramamento.

Este é o Sql Server 2019. O recurso de concessão adaptável (2017) deve estar ajustando a concessão devido ao derramamento? Executá-lo repetidamente no SSMS e no plano de visualização parece indicar nenhuma alteração.

select top (@pMax)
           aig.ObjectId,  
           iif((@pA in (1, 2, 3, 4, 5, 6, 9, 11, 12) and ttm.ObjectId is not null) or
               (@pA in (7, 8, 10, 13, 14, 15)), 1.0, 0.0) as Rank
      from oav.value aig               
      inner merge join Pub.CachedObjectHierarchyAttributes coha
        on coha.ObjectId = aig.ObjectId
       and coha.IsActiveForPublisher = 1
       and coha.IsToolItem = 1
      inner merge join Oav.ValueArray v897
        on v897.PropertyId = 897
       and v897.ObjectId = aig.ObjectId
       and v897.[Value] = @pBrandId
      left hash join oav.valuearray ttm      
        on ttm.ObjectId = aig.ObjectId
       and ttm.PropertyId = 11131  
       and ttm.[Value] = @pToolTypeMapId 
     where aig.PropertyId = 2573        
       and aig.[Value] = @pA
     order by ttm.[Value] desc -- to put TTM matches at the top
     option (maxdop 1); -- limit to 1 cpu since it runs across all pubs

As estimativas de linha do índice 3 buscam a correspondência certa dentro de <1% das linhas reais.

No entanto, a estimativa para a primeira mesclagem das 2 buscas mais à direita está um pouco errada e, em seguida, continua causando os vazamentos. Com estimativas perfeitas das 2 etapas anteriores, o que resta para afetar essa estimativa?

Detalhe do derramamento: