Pre-existing defect affecting BOTH execution paths (native aggregation pipeline AND the driver-LINQ fallback) — surfaced while reviewing EF-336 (native scalar cardinality), but not introduced by it.

When an aggregate selector (or a predicate/sort key) references a property whose stored BSON type diverges from its CLR type via a non-default BsonRepresentation (e.g. an int/decimal stored with HasBsonRepresentation(BsonType.String)) or a value converter, the server-side operation runs against the raw stored representation:

• Sum(e => e.Price) over values stored as strings "9"/"10"/"100" returns 0 (via $sum on non-numeric BSON).
• Min/Max order lexicographically ("10" [ "100" < "9"), not numerically.

Verified reproducing under BOTH MongoQueryMode.Native and MongoQueryMode.DriverLinq — i.e. the driver-LINQ pushdown of $sum/$min/$max has the identical bug. Root cause: MongoExpressionTranslator.TryResolveMember (native) resolves a member to a bare field ref with no awareness of the property's representation/converter, and the driver's LINQ provider likewise pushes the aggregate onto the stored field.

Because both paths share the defect, a native-only fallback guard would NOT fix it. The fix belongs in a shared layer: either detect a non-identity representation/converter on the aggregated/compared field and refuse the server-side pushdown (materialize + compute client-side), or emit an explicit $toDecimal/$toInt/$toDouble conversion in the pipeline. Scope should also consider predicate comparisons and sort keys over such fields (same field-ref limitation from EF-329).

Not a blocker for EF-336 (no regression — behavior is unchanged from before the native path existed). Filed for separate scheduling.</description]
[parameter name="additional_fields"]