Entity `RETURN DISTINCT` followed by `UNION` fails with `type with OID ... does not exist`

**Reproduction**

```sql
LOAD 'age';
SET search_path = ag_catalog, public;
SELECT ag_catalog.create_graph('age_issue_case18');

SELECT *
FROM ag_catalog.cypher('age_issue_case18', $$
CREATE (n {id: 1})
$$) AS (v agtype);

SELECT *
FROM ag_catalog.cypher('age_issue_case18', $$
MATCH (n)
RETURN DISTINCT n AS value
UNION ALL
RETURN null AS value
$$) AS (value agtype);
```

**Expected**

The query returns the matched vertex and one `null` row. `UNION ALL` permits
both rows, and `null` is a valid value for the same result column.

**Actual**

```text
ERROR: type with OID 4026532032 does not exist
```

The numeric OID varies with the fresh database. It is generated internally;
there is no OID or type name in the Cypher input. The failure reproduces on a
fresh AGE 1.8.0 / PostgreSQL 18.6 graph.

**Controls**

The following queries succeed on the same graph:

```cypher
MATCH (n)
RETURN n AS value
UNION ALL
RETURN null AS value
```

```cypher
RETURN 1 AS value
UNION ALL
RETURN null AS value
```

The failure therefore requires the entity branch's `RETURN DISTINCT` path;
it is not a user-supplied missing-type or missing-OID error. The original
audit Cases 951, 1167, and 1888 are deduplicated under this one family. Case
1167 uses `UNION ALL`; Cases 951 and 1888 use the default `UNION` spelling.

**Environment**

Apache AGE `1.8.0` on PostgreSQL `18.6`, Docker image
`apache/age:release_PG18_1.8.0`.

Run the supplied reproduction on AGE 1.8.0/PostgreSQL 18.6 first, then compare it with the two control queries. Trace the entity branch through RETURN DISTINCT and UNION type handling; done means the reproduction returns the vertex and null row without the OID error while both controls still succeed.

Written by the indexing model from the issue text.