Cypher executor does not leverage indexes for property matching on agtype columns

## Summary

The Cypher executor's pattern matching (`MATCH (n:Label {key: value})`) does not leverage GIN or btree indexes on the `properties` agtype column. This forces sequential scans even when appropriate indexes exist, resulting in significantly slower property-based lookups compared to native PostgreSQL index usage.

## Reproduction

Setup: 100K nodes in a graph with a GIN index on the `properties` column.

```sql
-- Create GIN index on properties
CREATE INDEX ON benchmark."Node" USING GIN (properties);

-- This Cypher query does NOT use the index:
SELECT * FROM cypher('benchmark', $$ MATCH (n:Node {bench_id: 42})-[e]->(m) RETURN m $$) AS (v agtype);

-- EXPLAIN ANALYZE shows Seq Scan on "Node" table
```

## Performance Data

Benchmark W04 (pattern match — find neighbors of a node by property):

| Approach | 10K scale | 100K scale |
|---|---|---|
| Cypher executor (no index use) | ~1ms | ~1ms |
| SQL JOIN with materialized column + btree index | 0.14ms | 0.14ms |

The SDK workaround materializes properties into native PostgreSQL columns and uses SQL JOINs to bypass the Cypher executor entirely.

## Expected Behavior

`MATCH (n:Label {key: value})` should push property predicates down to PostgreSQL's index scan when a GIN index exists on the `properties` column, similar to how `jsonb @> '{"key": "value"}'` leverages GIN indexes.

## Environment

- PostgreSQL 18.2
- Apache AGE 1.7.0 (built from source, branch `release/PG18/1.7.0`)
- 32-core, 64GB RAM, Linux 6.17