Redundant outer DISTINCT adds Sort and Unique above EXCEPT

[陈列行]

## Description

This issue concerns an outer `DISTINCT` applied to an `EXCEPT` result.
Non-`ALL` `EXCEPT` already removes duplicates, so applying `DISTINCT` again
is semantically redundant. PostgreSQL retains the additional operation.

### Expected Behaviour

PostgreSQL should use the duplicate-free property of `EXCEPT` and eliminate
the outer `DISTINCT`. The original and simplified forms should receive
equivalent plans.

### Actual Behaviour

The outer `DISTINCT` adds `Sort -> Unique` above `HashSetOp Except`. With
two 500,000-row inputs and 250,000 result rows, five-run medians were
184.393 ms with the redundant operation and 181.401 ms without it,
approximately 1.6% slower. This timing difference is small enough to overlap
runtime variation, but the extra plan operators are deterministic.

## How to repeat

```sql
DROP TABLE IF EXISTS except_distinct_lhs;
DROP TABLE IF EXISTS except_distinct_rhs;

CREATE TABLE except_distinct_lhs (v INTEGER NOT NULL);
CREATE TABLE except_distinct_rhs (v INTEGER NOT NULL);

INSERT INTO except_distinct_lhs
SELECT g FROM generate_series(1, 500000) AS g;

INSERT INTO except_distinct_rhs
SELECT g FROM generate_series(250001, 750000) AS g;

ANALYZE except_distinct_lhs;
ANALYZE except_distinct_rhs;

EXPLAIN (ANALYZE, BUFFERS, VERBOSE, SETTINGS, TIMING OFF)
SELECT DISTINCT v
FROM (
    SELECT v FROM except_distinct_lhs
    EXCEPT
    SELECT v FROM except_distinct_rhs
) AS set_result;

EXPLAIN (ANALYZE, BUFFERS, VERBOSE, SETTINGS, TIMING OFF)
SELECT v
FROM (
    SELECT v FROM except_distinct_lhs
    EXCEPT
    SELECT v FROM except_distinct_rhs
) AS set_result;
```

Both queries return the same 250,000 rows. The characteristic plans are:

```text
with DISTINCT: Unique -> Sort -> HashSetOp Except
without:       HashSetOp Except
```