Cleanup ConnectionQuery | Simplify child nesting strategy

[jonkjetiloye]

Problem

The delayChildNesting and delayFromFilter flags exist because joining children in SQL causes bad Postgres query plans for large FromId sets in the FromOthers direction. The current approach conditionally nests children either in SQL (small sets) or in-memory (large sets), creating two code paths through both BuildBaseQueryFromOthers and EnrichEntities.

Goal

A single, simple child nesting strategy with no conditional branching.

Approach

Always perform child nesting in-memory (post-query) for the FromOthers direction. This path already exists and is proven for large FromId sets.

Work

• Remove delayChildNesting and delayFromFilter parameters from BuildBaseQueryFromOthers
• Remove the SQL child-nesting JOIN from BuildBaseQueryFromOthers (the fromChildren variable)
• Always perform child expansion in ConnectionEntityEnricher.ApplyEnrichment() for FromOthers
• Remove the conditional branching in GetConnectionsAsync that decides between SQL vs. in-memory nesting
• Performance test: compare before/after for AuthorizedParties and PIP with small FromId sets (≤20)
• Verify integration tests still pass

Out of scope

• Removing innehaverConnections logic (that stays in the SQL query)
• Changing ToOthers direction behavior

Constraints

• No change in query results
• Performance must not regress for AuthorizedParties or PIP. If measurement shows regression for small FromId sets, consider a simpler threshold-based approach with clear documentation

Depends on: sub-issue 5 (entity enricher extraction) and sub-issue 6 (query builder extraction)