Conditional .Having(...) on a split GroupBy chain is not mask-gated — HAVING renders unconditionally

[DJGosnell]

Description

A conditional (if-gated) .Having(...) on a GroupBy chain split across a reassigned local variable makes the generator lose the chain root's context type. When two contexts both expose an accessor for the same entity (CteDb and TestDbContext both have IEntityAccessor<Order> Orders()), the chain binds to the wrong context and renders wrong-dialect SQL.

Previously noted only as a prose comment ("Filed as follow-up") with no tracking issue — split out of #314's finding 5.

Location

• Trailing NOTE documenting the routing-around: src/Quarry.Tests/SqlOutput/CrossDialectConditionalMaskTests.cs (end of file, "NOTE: A conditional-Having test ... currently triggers a generator misattribution")
• Chain-root context resolution during binding: src/Quarry.Generator/IR/CallSiteBinder.cs / src/Quarry.Generator/Parsing/ChainAnalyzer.cs (context type lost across the GroupBy/Having variable split)

Diagnostics

Repro shape:

var ltG = lt.Orders().GroupBy(o => o.Status).Select(g => (g.Key, Total: Sql.Sum(g.Value.Amount)));
if (cond)
    ltG = ltG.Having(g => Sql.Count() > 1);
var results = await ltG.ExecuteFetchAllAsync();

With both CteDb and TestDbContext in the compilation exposing Orders(), the chain binds to CteDb — SQL renders with CteDb's dialect/schema instead of the actual receiver's.

What Has Been Tried

Nothing — the test that would exercise this was deliberately omitted (single-line GroupBy chains work; see CrossDialectAggregateTests). Note in the test file records the behavior.

Gathered Information

• Single-line (unsplit) GroupBy/Having chains bind correctly.
• The misattribution requires (a) variable split across the GroupBy/Having boundary, (b) conditional extension, (c) ambiguous accessor (two contexts exposing the same entity accessor).
• A pinning test asserting the current (buggy) binding is being added by Test suite guardrails: hollow incremental-caching tests, no perf regression gate, concurrency insurance, row-order flakes, manifest goldens, streaming/cancellation #314 so this issue's fix will surface as that test failing.

Suggested Approach

During chain-root resolution, retain the receiver's context type through builder-variable reassignment (track the local's declared/inferred builder generic arguments rather than re-resolving by entity type). Failing that, detect the ambiguity (multiple contexts exposing the entity) and emit an actionable QRY diagnostic instead of silently binding to the wrong context.

[DJGosnell]

Empirical update while working #314: the context misattribution described in the original body no longer reproduces — a split conditional-Having chain now binds to the correct context and renders correct per-dialect SQL (likely fixed by the #307/#322 conditional-mask work; the test-file NOTE was stale).

What DOES reproduce is a different defect in the same shape: the conditionally-applied .Having(...) is not mask-gated. The generated SQL contains the HAVING clause unconditionally, so the untaken runtime branch still filters groups (verified on all 4 dialects, SQL + execution).

Coverage added by #314 in CrossDialectConditionalMaskTests:

• Mask_ConditionalHaving_SplitChain_TakenBranch_CorrectSqlAndRows — correct-behavior regression test (attribution + taken branch).
• KnownBug_Issue328_ConditionalHaving_UntakenBranch_StillRendersHaving — active pin asserting the buggy unconditional rendering; when that test fails, this issue is fixed — flip the pin to expect no-HAVING SQL and all status groups.

Retitled the issue accordingly; treat the original body's misattribution description as historical.