#4677 follow-up — object-projection aggregates + post-SelectMany Select/Where

[jeremydmiller]

Stacked on top of #4677 — must merge after #4677 (the diff includes that PR's commits because the base branch lives on the contributor's fork and isn't reachable from this remote). Addresses the two Known limitations that #4677 explicitly left open:

1. Aggregates over an object projection.
   .SelectMany(.., (x, c) => new {..}).Sum(z => z.X) (which QueryableExtensions
   lowers to .Select(z => z.X).SumAsync()) used to hit
   JoinSelectClause.ApplyOperator(\"SUM\") on the object projection and throw the
   clear-error pin shipped in Fix several LINQ gaps: DateOnly/TimeOnly projection, SelectMany Distinct().Count(), and GroupJoin Distinct/scalar/aggregates #4677.

2. .Select(...) / .Where(...) after the join's .SelectMany(...).
   CompileGroupJoin ignored both: a post-SelectMany Select returned the original
   anon-typed rows and a post-SelectMany Where was silently dropped.

Approach

The fix is a single seam in CompileGroupJoin — a new AnonProjectionExpander
visitor walks the FlattenedResultSelector's (x, c) => new { Member = source }
bindings and rewrites a z.Member access (on a parameter of the projection's
anon type) back to its source expression in (x, c) terms.

With the expander in hand:

• Post-SelectMany Select(z => ...) reduces to a synthesized effective
  result selector that JoinSelectParser then renders normally — including
  lighting up the bare-scalar aggregate path that already handles
  Sum/Min/Max/Average over a scalar projection.
• Post-SelectMany Where(z => ...) filters get expanded the same way and
  routed onto the appropriate CTE's existing Where pipeline — inner-side onto
  InnerCollectionUsage.WhereExpressions before its ParseWhereClause runs;
  outer-side onto outerStatement.ParseWhereClause after the fact with
  storage=null so we don't double-apply tenant / soft-delete defaults.

Both Select and Where walk the Inner chain (Inner and Inner.Inner)
the same way SingleValueMode / IsDistinct already do — re-linq sometimes
pushes a post-SelectMany Select onto a new usage because the element type
changed, so the operators don't always sit on Inner directly.

Pinned limitations (clear-error, not silent)

• Cross-side Where filters that touch both x.* and c.* on the
  projected anon type throw BadLinqExpressionException. Would need a
  join-level WHERE clause in JoinSelectClause; left for a follow-up.
• Computed expressions on projected members (z.Amount * 2) inherit the
  existing "computed scalar projection" pin from Fix several LINQ gaps: DateOnly/TimeOnly projection, SelectMany Distinct().Count(), and GroupJoin Distinct/scalar/aggregates #4677 — no change.

Tests

11 new tests in Bug_4677_groupjoin_post_selectmany.cs:

• object_projection_sum_of_inner_member / _of_outer_member / _min_and_max
  / _average_returns_double / _sum_over_left_join_ignores_unmatched
• post_select_many_select_reduces_to_scalar_member
• post_select_many_select_reshuffles_to_new_anonymous_type
• post_select_many_where_filters_on_inner_member / _on_outer_member
• post_select_many_where_then_sum_chains (both fixes in one chain)
• post_select_many_where_touching_both_sides_throws_clear_error (limitation pin)

The 53 existing tests across Bug_groupjoin_distinct_and_scalar_projection,
Bug_distinct_count_over_selectmany, Bug_dateonly_timeonly_scalar_projection,
and the group_join_operator family stay green. Full LinqTests suite passes
on both net9.0 and net10.0 (1312 / 1313 — 1 unrelated pre-existing skip).

🤖 Generated with Claude Code