Native LINQ query rewrite sub-project SP4 (epic EF-322). Pushes scalar cardinality and aggregate operators onto the provider's native aggregation-pipeline path, so they no longer round-trip through the driver-LINQ provider.

Two mechanisms:

• Entity reducers — First/FirstOrDefault/Single/SingleOrDefault: a synthesized $limit (1 for First-family, 2 for Single-family so ">1" is still detectable) plus EF Core's own base cardinality reduction over the returned IEnumerable<T>. Reuses the existing entity DOM shaper.
• Scalar aggregates — Count/LongCount/Any/All/Sum/Min/Max/Average: new $count/$group/$limit stage IR + a DOM scalar shaper reading a single field, with an explicit empty-input contract matching BCL LINQ (Count/Sum -> typed 0, Any -> false, All -> true, nullable Min/Max/Average -> null, non-nullable -> throw "Sequence contains no elements").

Retires two cutouts: the ExecuteScalar short-circuit (now gated on NativePipeline == null) and the resultCardinality != Enumerable native-gate exclusion.

Falls back to driver-LINQ (correct results; throws under NativeOnly): Contains/ElementAt/Last; computed aggregate selectors; All with a comparison predicate (follow-up EF-335); an aggregate that injects a predicate as $match (or a reducer) after a Take/Skip already applied (canonical-order guard); reducer/aggregate streaming (DOM only for now).

Native becoming the default path for these operators and the changed emitted MQL are implementation details, not breaking changes (per the provider's versioning rubric) — query results are unchanged. Native-only spec coverage improved from 2019 to 2165 passing with zero regressions; EF8/EF9/EF10 suites green. Also turned 3 previously-failing spec tests green (EF-X011 compiled-query xfail; EF-227 nullable Min/Max over empty now correctly returns null).

Design + plan: docs/superpowers/specs/2026-07-07-native-scalar-cardinality-design.md, docs/superpowers/plans/2026-07-07-native-scalar-cardinality.md.