SELECT DISTINCT x, y FROM t is currently blocked with FeatureNotSupportedException("SELECT DISTINCT is not supported").
It is semantically equivalent to SELECT x, y FROM t GROUP BY x, y and maps directly to the same MongoDB pipeline shape.

Pipeline shape and assumptions:

We could group on individually extracted scalar fields:

{"$group": {"_id": {"city": "$city", "primitiveInt": "$primitiveInt"}}}

Scalar fields have no internal order, so field-order sensitivity does not apply. This appears to be correct
for any data in the collection regardless of how it was written. 

Example:

SELECT DISTINCT b.primitiveInt, b.string FROM Item b ORDER BY b.primitiveInt

[
  {"$group": {"_id": {"primitiveInt": "$primitiveInt", "string": "$string"}}},
  {"$sort": {"_id.primitiveInt": 1}},
  {"$project": {"_id#primitiveInt": "$_id.primitiveInt", "_id#string": "$_id.string"}}
]

Implementation approach

When selectClause.isDistinct() is true, treat the query as if it is in AFTER_GROUP state:

1. Synthesize group keys from the selected column references - same logic as createGroupStage but driven by the SELECT list instead of getGroupByClauseExpressions().
2. Emit the synthesized $group stage.
3. Set groupByContext to AFTER_GROUP phase so resolveFieldPath and the rewriter rewrite column refs to _id.<subKey> in ORDER BY and the $project.

No new phases needed - reuse the existing GROUP BY machinery as-is.

Acceptance criteria

• SELECT DISTINCT x FROM t emits $group + $project.
• SELECT DISTINCT x, y FROM t emits correct multi-key $group.
• SELECT DISTINCT x FROM t ORDER BY x rewrites x to _id.x in $sort.
• SELECT DISTINCT x FROM t WHERE x > 1 emits $match before $group.
• SELECT DISTINCT x FROM t GROUP BY x throws FeatureNotSupportedException.
• Integration tests in a new DistinctIntegrationTests class.